[lug] security for modules?

[David Trowbridge]

At this point, you're pretty much dealing with a kernel-level security
system, of which there are several:

Medusa - http://medusa.fornax.sk
LIDS - http://www.lids.org
And these others, for which I do not have URL's
RSBAC
NSA slinux
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
>