[lug] security for modules?

Wed Jun 20 22:48:54 MDT 2001

Since medusa seems inaccesible, I'll comment on what it is and why I like
it.

First, whats good about it:
Medusa is separated into two parts: kernel implementation and a user-space
daemon. The kernel code is fairly small, being merely hooks placed
whenever something interesting happens. When the daemon (called
'constable') isn't running, the system acts as if medusa were not even
there. The daemon itself runs off of a script loosely based on C.

Because its scripted, you can make it do pretty much whatever you like.
Its fairly simple to mess with capabilities or make a file append-only or
prevent killing of the constable. If you put your mind to it, you can do
some truly clever things. A couple examples: (1) separate processes into
local and network groups, and restrict the network processes. You can even
have different password files for if somebody is logging in on the console
or remotely. (2) Force execution of arbitrary code. I wrote a password
module that did a sort of sudo execution but even for root on certain
actions.

One nice thing I did with it (and posted to sourceforge) is write a toggle
program. It requires a password, but works under the assumption that you
make any changes to the medusa configuration in a secure environment
(logged in on the console, probably in single user mode with no programs
running). Of course, both the medusa config and the toggle program would
be immutable.

That being said, there is one big downfall which is currently being
corrected: medusa is somewhat out of date. Development was halted for 6 or
7 months, during which the kernels continued to progress. But they're
working on it again.

Now, to address some of the concerns I've heard on this thread:
Raw disk access is easily removed, either via CAP_SYS_RAW or disabling
read/write to the device file except for the programs that need it (raw
memory access is required by X, for example).
The system can be reconfigured without a reboot. Using my little prog, for
instance, you can turn off everything.

To check any file named 'ls', here's how I'd do it: Set up an 'on exec'
handler that checks argv[0] for 'ls.' After that, write (or steal) a
signature checking routine in C, and force the code. If the signature
checks out, let it run. Else, exit(1).

Hope this explains it and maybe encourages some of you to try it. Like
UNIX in general, it doesn't prevent you from doing stupid things, so I
suggest you keep a spare kernel around.

Have fun.
-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, D. Stimits wrote:

> 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
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>