New kernel out (2.4.20, Nov 28, 2002)

ME dugan at
Sun Dec 1 15:50:10 PST 2002

Doug Palmer said:
> If such a speech occurs, I would like to see what people recommend for
> kernel config options in a couple of environments (server v.
> workstation.) Like when is it better to compile stuff into the kernel or
> is a module a better choice, and which stuff is _required_ for a secure
> system.

Generally speaking (or writing ;-), it is a good idea to enable all kernel
options as modules. There are exceptions.

When making a "secured shell server" I find it a good idea to make
*nothing* into a module. This can create problems and limits options for
the booted system. (Better described below.)

When making a solid-state machine w/o an HD and limited space, making all
parts into a monolithic kernel is a good idea to save space, where
inefficient use of file space is a problem on limited space media.

You should probably enable support for any hardware required for a boot
into the kernel and *not* as a module. An example:
Make IDE support a kernel built-in if you boot from an IDE based disk.
Make SCSI disk support a kernel built-in if you boot from a SCSI based disk.
If you want "software RAID support from the boot disk" then you need to be
a bit more clever and do the boot from an an initrd. This makes a
requirement for many options to be part of the kernel not as strong.
(Also, I found that RedHat seems to make their bootable system use initrd
based kernels so that support for RAID on "/" is possible. I am a
Debian-guy, but find this feature from RedHat (as a deafult) a rather nice

(There are other cases when a monolithic kernel (one without any module
support is included) is a good idea.)

Costs of choosing to not enable loadable modules:
You cant add hardware that you did not account for when configuring the
kernel you compile and use unless you compile another and reboot.

Unloading and re-inserting modules to specify other flags (such as Media
speed for networking (10/100Mbps, full/half duplex, etc) become more
difficult or impossible unlessyou reboot.

Problems enountered with AppleTalk (using the appletalk driver in Linux
for AppleTalk with netatalk) may remain unless you reboot. ("things" can
be set when loading an appletalk module that are not easily "unset" unless
you can temporarily turn-off appletalk and reset kernel options required
by appletalk. (Such issue seldom *ever* come up, but when they do on a
server, you can just stope the netatalk services, *and* unload the kernel
module and then reload the kernel module and start netatalk to be sure you
are starting from a "clean slate."

Generally speaking, having module support is a good thing. Most desktop
machine *should* have module support and everything made into a module
that is not required for a boot.

Most *server* should have support for loadable modules and make all
drivers not required for a boot into modules if possible.

I choose to disable support for *any* modules on shell servers, and
servers whose puspose requires a lot of security (syslog servers for
example) to help decrease risk for a trojaned module being dumped and
hidden doing "who knows what." If there is no support for modules, it will
be rather difficult for a modules to be loaded.

Dustin pointed out to me recently that he uses a special module(s) to
disable post-loading of modules after the special mdoules. (This is placed
here so that you know there is another option.)

And if your focus is security, there are kernel security patches available.

I used S.D. kernel security enhancements, and have used a few different
kernel patches to provide enrypted file support.

The thing to remember is:
The kernel is only one piece of a server's security. Making a kernel
uber-secure does little if the services aren't.

If you permit other users to have shell access, then local application
security is yet another thing to examine very closely.


Version: 3.12
GCS/CM$/IT$/LS$/S/O$ !d--(  ) !s !a   (-----) C  $(    ) U    $( $) P $>
L   $(  ) E W   $( ) N  o K w $>  >    O-@ M $ V-$>- !PS !PE Y  PGP
t at -(  ) 5 @ X@ R- tv- b   DI    D  G--@ e >  >     h(  )>  r*>? z?
decode: about:
  Campus IT(/OS Security): Operating Systems Support Specialist Assistant

More information about the talk mailing list