[lug] security for modules?

George Sexton gsexton at mhsoftware.com
Wed Jun 20 21:19:03 MDT 2001


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.

>> 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.


>> 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.

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.

>>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:

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.

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.

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.

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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
_______________________________________________
Web Page:  http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug




More information about the LUG mailing list