[lug] security for modules?

[George Sexton]

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.

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