[lug] security for modules?

[D. Stimits]

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