[lug] security for modules?

[D. Stimits]

George Sexton wrote:
> 
> Well, there are a couple points
> 
> >>What is to stop someone who has managed root access from modifying
> >>rc.local...would this be one of the files marked as permanently
> >>immutable? If immutable, is this really permanent, or only permanent
> >>until the next reboot, if rc.local is edited first?
> 
> If you make a file immutable using chattr, it cannot be changed until you
> clear the immutable flag again using chattr. If you disable CAP_IMMUTABLE
> (or something similar), then the attribute cannot be removed until the
> system is rebooted. Typically, you would boot into single user, change the
> immutable flags, perform the update, reflag the files immutable. The
> CAP_IMMUTABLE flag is cleared when the system goes multi-user.
> 
> Once the capability is disabled for loading modules, it can't be re-enabled
> without re-booting. This keeps someone from coming into your system and
> loading a module to do something sneaky. They would have to set it to load
> and re-boot the computer.

This seems to be related only to file existence, and modification, but
what if someone adds their own module and tries to load it, is this
prevented? Does that also mean that the legitimate admin cannot add new
modules without a reboot? Would it be typical to make the whole
/lib/modules/ directory immutable? If not, nothing could be done to stop
a root intruder from adding a new module there...either the regular
system owner or the root intruder could then tell it to reboot. But I
guess what I'm suggesting is a form of immutable flags, but whereby
files that are properly signed can ignore this. No reboot needed, and
provided you have the private key to sign things, normal operations
continue.

> 
> >> My goal was not to make files immutable, but to have unsigned files
> >> rejected, probably on a per-directory basis, but in general the main
> >> target would be kernel modules. Maintenance could be achieved by
> 
> No single approach gives the best results. The best results come from using
> all available techniques to create a layered security system.

Agreed. I was, however, thinking that instead of cutting out normal
functionality in order to keep it from being vulnerable, instead keeping
all that functionality provided you had a private key to sign with.
Having that cake and eating it too. Removing or butchering full system
freedom tends to make the machine less useful except in cases where it
is totally dedicated to one function. Imagine a production web server
that you have to reboot to add new web pages to, versus one that allows
index.html to be altered only if it passes a signature test (I've seen a
number of attacks on my computer from machines that were "defaced by
mafiaboy"). The named approach does still require that the BIOS be set
to not allow boot sector alteration without a pass (which in turn only
works at the console, prior to o/s loading, typically labelled as boot
sector virus protection).

> 
> >> My goal was not to make files immutable, but to have unsigned files
> >> rejected, probably on a per-directory basis, but in general the main
> >> target would be kernel modules. Maintenance could be achieved by
> 
> I liked the idea of requiring signed modules. You could do something like:
> 
> Hack module loader to use DSA/SHA and private/public key cryptography. Have
> a signature file that contains the DSA/SHA values for each allowed module.
> The kernel loader then compares the signed value with a computed value on
> the module. The private key used to sign the modules could be kept on the
> system, but Triple-DES encrypted. The public key of course would be kept on
> the system with the signature file and used in the check operation.

Personally I'd keep it on a floppy in a safe if possible, else on an
encrypted partition (maybe even an encrypted cd rom). But this is
exactly the modification I had in mind.

> 
> You could also, I guess, have a "additional module dirs" file that would
> have a signature you could verify in the same manner as above. You don't
> want to code these as constants in the kernel, it would be too icky and
> would probably be rejected out of hand.

I considered any files separate from the kernel to be a risk. So I'd
want to have the signatures selectable at compile time, and no other
file would be consulted. It might be interesting if instead of simply
signing modules, they were actually encrypted via the key, and only
modules that were valid after decrypting would load...but then you'd
risk having to have the private key built into the kernel, so I'd opt
only for the ability to validate signatures (I think this could be done
without a full private key built into the kernel...only signatures would
be required). Whether that would be rejected by the kernel dev people I
don't know, but I suspect I know too little about kernel code for
anything I write to make it in (I like C++, though my origins are
C...the kernel list would shudder). But this sort of data wouldn't be
all that bad, it is just an array of char, which could itself be a
module (don't forget to sign it!) that is part of an initial ramdisk
(maybe named "fingerprint.o").

> 
> >>One other possibility to consider is this: assume you make "ls" or "ps"
> >>immutable. But someone sticks a replacement version earlier in root's or
> >>some other user's path. Compare that to a kernel that accepts files
> >>named "ls" only if they are signed by the correct pgp style keys...it
> 
> So, what you are essentially talking about is making a class of "protected"
> file names that the system would honor. It would be a pretty big job. You
> would have to hook into the kernel in several places. Another issue is this:

This would be a second level of implementation. I'm saying that if
modules were protected by signatures, much of what is needed would
already be in place to extend this to either file names or
directories...in general, nodes. But yes, it is a suggestion that the
module system can be extended to make a class of protected names that
the kernel itself deals with, such that they are only protected if
modification would violate the signature. Anyone who could sign a new
"ls" or "ps" or anything on the list with a proper pgp signature could
alter it as if it was not protected.

> 
> If the user gets root, then they will have enough privilege to get RAW
> access to the disk devices and pretty much subvert your whole "magic
> filename/signature" idea. This is why immutable is pretty much unused. Quite
> simply, if I get access to the magic file list then I can truncate it and
> subvert the whole thing.

I assume that the BIOS has boot sector modification protection (BIOS
virus protection), so that a boot sector can't be modified without
sitting at the machine and giving a password before the o/s even loads.
Next, I assume that the kernel images themselves that lilo pointed at
during the time of lilo update are on the list of files that the kernel
will not allow to be modified if it violates the signature. So compiling
a new kernel, placing it in /tmp/, then trying to run lilo will fail due
to BIOS restrictions. Attempting to modify the actual kernel that boot
sectors point at would fail due to signature violations. It in no way is
designed to protect from a local cracker sitting at the console with a
boot floppy. I have assumed, however, that raw access cannot be made
without going through a kernel system call. Is this assumption
incorrect? Can the filesystem be altered directly from a remote location
(with root access) without the kernel being involved?

> 
> Putting the magic file list in the kernel would only help if the list were
> loaded into memory at boot time and kept there. So, you are still stuck with
> the issue that if you want to change a magic file you have to reboot.
> Incidentally, I could use raw access, change the DATA structures stored in
> the kernel and eliminate the magic file list from the kernel image as well
> and then reboot the machine.

For modules I assume a blanket rule could allow this to exist without a
specific module list. If it is extended to include directory or file
names, yes, I would want the list to be compiled directly into the
kernel; but for example, naming "/boot" would cause this behavior to be
inherited by any file in /boot, so nothing could be added or modified in
/boot or its subdirectories unless it matches an accepted signature.
Creating the list as a module should be fine as well, because modules
can't be modified without themselves being properly signed. Let's say
you wanted to update the list of signatures without rebooting, here is
how you would do it: Compile the updated list as a module, in the normal
way. Sign the module. Now move it to the /lib/modules/whatever/,
overwriting the old one. If the signature did not match, it would not be
allowed; if it matches, it is allowed. Then reload the module. If this
is extended to files (and in the case of a signed directory, it would
mean all files within it must be signed no matter what the file name),
you create your replacement in an unprotected directory, sign it there,
then mv it in to the protected area. No reboot.

The main concern is doing this in such a way that kernel memory
containing signatures cannot itself be altered.

> 
> The best ideas I have seen is to put the important file systems onto a
> read-only media (CDROM or SCSI drive with WriteProtect jumper) and
> changeable data (/var, /tmp, /home on writable media). When it's time for
> maintenance, you boot into single user mode, put the media into read/write
> mode make your changes, flip the switch and reboot.

This is the safest way, but it leaves a lot to be desired for a lot of
environments, along with requiring the hardware to support it. This is a
software-only solution, not requiring reboot.

D. Stimits, stimits at idcomm.com



> 
> George Sexton
> MH Software, Inc.
> Voice: 303 438 9585
> http://www.mhsoftware.com
> 
> -----Original Message-----
> From: lug-admin at lug.boulder.co.us [mailto:lug-admin at lug.boulder.co.us]On
> Behalf Of D. Stimits
> Sent: 20 June, 2001 7:41 PM
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] security for modules?
> 
> George Sexton wrote:
> >
> > One thing that is generally not know is that you can adjust the system
> > capabilities to disallow loading and unloading modules. Essentially, you
> > make the change to the capabilities in your rc.local at boot time. Once
> they
> > are set, you cannot change them back.
> 
> What is to stop someone who has managed root access from modifying
> rc.local...would this be one of the files marked as permanently
> immutable? If immutable, is this really permanent, or only permanent
> until the next reboot, if rc.local is edited first?
> 
> My goal was not to make files immutable, but to have unsigned files
> rejected, probably on a per-directory basis, but in general the main
> target would be kernel modules. Maintenance could be achieved by
> compiling and signing new modules or files without rebooting, while
> still refusing even root the ability to replace or modify those items if
> the replacement or modification does not follow the right signature.
> 
> One other possibility to consider is this: assume you make "ls" or "ps"
> immutable. But someone sticks a replacement version earlier in root's or
> some other user's path. Compare that to a kernel that accepts files
> named "ls" only if they are signed by the correct pgp style keys...it
> wouldn't matter where in the system the cracker tried to place it, it
> would refuse to move, alter, or add a file named "ls" if it did not have
> the right signature. The signature could be one of whatever was used
> during kernel compile, such as Redhat having a signature on their
> distribution, or local companies only allowing the key of various
> administrators. (something could also be worked out for symbolic links
> and multiple hard links)
> 
> D. Stimits, stimits at idcomm.com
> 
> >
> > You would probably want to look at:
> >
> > /usr/src/linux/include/linux/capability.h
> > /proc/sys/kernel/cap-bound
> >
> > I dug into this awhile ago, looking at immutable files. I know that
> support
> > for capabilities was made better in the 2.4 series, but I have never gone
> > back and looked at it.
> >
> > George Sexton
> > MH Software, Inc.
> > Voice: 303 438 9585
> > http://www.mhsoftware.com
> >
> > -----Original Message-----
> > From: lug-admin at lug.boulder.co.us [mailto:lug-admin at lug.boulder.co.us]On
> > Behalf Of D. Stimits
> > Sent: 18 June, 2001 2:05 PM
> > To: BLUG
> > Subject: [lug] security for modules?
> >
> > I was thinking about one of the current problems with security, where a
> > module can be inserted to tell the kernel to lie about the presence of
> > modules and/or files. I'm wondering what flaws the following might have
> > in it:
> >
> > Imagine that the ability to compare pgp (gpgp) signatures was compiled
> > into the kernel itself, along with a list of acceptable signatures.
> > I.E., the list could not be removed from the kernel, nor could it be
> > added to or modified once compiled. Also imagine that the kernel would
> > check any module to be loaded, and reject any module not signed. As one
> > possibility, a distro such as Redhat could sign modules from its install
> > setup with its private key, and if the "secure module" kernel were used,
> > then only those modules with redhat signatures could be loaded. If you
> > wanted to add other modules later, you would have to recompile the
> > kernel and list acceptable signatures at that time, perhaps taking and
> > accepting the fingerprint off of an existing RH module, and adding your
> > own on top of that (or that of a few admins at the local shop). Thus it
> > would not matter who broke in, if the kernel itself was not replaced, it
> > would disallow altered modules, unsigned modules, and modules without a
> > signature that was specifically designated.
> >
> > The whole thing could be taken a step further, and compile time could be
> > set up such that particular files could also be named, in addition to
> > modules, such that they cannot be used unless they have the requied
> > signature...e.g., ls, rm, ssh, bash. Or a given directory could be
> > named, recursively, e.g., /lib, /bin, /sbin, such that only properly
> > signed files would be allowed in the directory.
> >
> > A related question about this is that although gpgp is available, I see
> > it is bound to a ton of gui and other libraries, and would not
> > necessarily be a good choice of sample code. Does anyone know of apps or
> > libraries that are available to verify pgp style signatures, but which
> > is not gui in nature? Whatever it is would have to be able to read and
> > compare signatures, but no ability to create would be required.
> >
> > D. Stimits, stimits at idcomm.com