[lug] security for modules?

[D. Stimits]

David Trowbridge wrote:
> 
> At this point, you're pretty much dealing with a kernel-level security
> system, of which there are several:
> 
> Medusa - http://medusa.fornax.sk

This link does not appear to be accepting connections, so I can't
comment on it.

> LIDS - http://www.lids.org

This one alters core system more than I'd like. I'm not interested in
immutable access, only being certain that kernel modules (and optionally
directories or file names) must pass a verification scheme. I'm thinking
of breaking root kits without breaking the administrator's ability to
modify at will. It's just that the administrator would have a private
key on a floppy or CD that is not accessible to the rest of the world,
and only the person with that key could sign new or replacement software
that would modify a protected module, directory, or file name. Features
like ACL's are already available if you use XFS.

The port scanner detector built into the kernel is also more intrusive
than I would like.

> And these others, for which I do not have URL's
> RSBAC

Don't know about this one.

> NSA slinux

I've seen this one. The URL:
http://www.nsa.gov/selinux/

I think it is also more intrusive than I'd like, modifying a lot more
than just the kernel. I think it might be possible to run signature
checking without modifying all of the related files too, such as glibc,
rm, cp, mv, so on. I'm looking at a purely kernel-only ability.

D. Stimits, stimits at idcomm.com

> I'm sure there are a few more too.
> 
> -David
> 
> -------------------
> David Trowbridge
> jupiter at flatirons.org
> http://jupiter.babylonia.flatirons.org
> 
> "Base 8 is just like base 10 really...if you're missing two fingers"
>         -Tom Lehrer
> 
> On Wed, 20 Jun 2001, 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.
> >
> > 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