[lug] security for modules?

Wed Jun 20 23:22:42 MDT 2001

David Trowbridge wrote:
> 
> 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

This sounds a lot closer to what I'd like than simply making some things
completely unwritable, but it might still leave some things to be
desired. For example, checking an argument for a directory name could
probably be circumvented in a number of ways, such as use of wildcards
and relative paths. If you cd to /usr, the following would all get to a
module directory (if you can get there, then the command can be altered
to do a number of other things as well, such as a redirected echo
command to fill in files or append):
cd /usr
ls /lib/modules/2.4.2-2
ls ../lib/modules/2.4.2-2
ls ../l*/m*s/2?4?2-2

I doubt the average script kiddie could succeed here, but I think a
blanket signature rule on a directory or on modules could go further.
And one *really* big advantage is that if it made its way into the
kernel source, and had no required external user space programs, then it
would be maintained by the kernel dev people and not require a separate
maintainer. If someone like RH were to sign all their modules and
activate this feature for module loading during default installs, there
would be a lot fewer root kits succeeding (although those same machines
could have other nasty things done to them via outside root access).
There are a lot of other things that need to be done to secure the
system, but medusa or signature systems would go a long ways to break
script kiddies.

D. Stimits, stimits at idcomm.com

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