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