OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: kauth, securelevel, and "run levels"

From: Elad Efrat (eladNetBSD.org)
Date: Sat Mar 25 2006 - 16:27:30 CST


Steven M. Bellovin wrote:

> Not really. Have a look at
> http://www.usenix.org/publications/library/proceedings/sec02/zhang.html
> -- it describes an automated analysis of the Linux kernel to ensure
> that certain checks were done at the right points.

For this reason, there are no new authorization requests anywhere in the
code (yet).

> I'm less concerned with the efficiency (a concern others have
> expressed) than with the correctness of the larger code.

The entire kauth(9) subsystem, contained within kern/kern_auth.c, is a
little over 800 lines of code, including spacing, comments, and license.

I invite anyone who is interested in the quality of the code, either in
the aspect of efficiency or security, to have a look at it and point out
what seems to be wrong or can be done better.

A link to the latest revision (for now) is:

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/kern/Attic/kern_auth.c?rev=1.1.2.24&content-type=text/plain

> That's where we disagree. I'm concerned not just with assurance for
> the programmer, but for the administrator of such a system. With the
> new scheme, when you set certain flags, do you have a clear
> understanding what is and isn't possible for an attacker? Securelevel
> can be described in a few paragraphs; you know what you're getting
> (modulo code bugs, but that's not what I'm talking about here).

While this is a valid concern, it is a well known fact in the Unix world
that a root user can very easily screw everything up. For that reason,
while I do understand the need of some people in multiple knobs, my
initial proposal suggested that we have *two* securelevel schemes that
can be used -- the existing scheme (default), and the multi-knobbed
scheme.

Furthermore, I even mentioned (and Thor mentioned it in his reply, too)
that we can ship default sysctl.conf-like files for those who choose
the new scheme with sane defaults.

So, if an admin chooses to, he can go the multi-knobbed way, and either
use or ignore the files we provide. There's so much we can do; I think
good documentation and sane defaults are enough.

-e.

--
Elad Efrat