[lug] security for modules?

D. Stimits stimits at idcomm.com
Mon Jun 18 14:05:20 MDT 2001


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



More information about the LUG mailing list