Subject: Re: kauth, securelevel, and "run levels"
To: Steven M. Bellovin <>
From: Elad Efrat <>
List: tech-security
Date: 03/26/2006 00:27:30
Steven M. Bellovin wrote:

> Not really.  Have a look at
> -- 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:

> 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

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.


Elad Efrat