Subject: Re: The reason for securelevel (was: sysctl knob to let sugid processes dump core (pr 15994))
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
From: Steven M. Bellovin <smb@cs.columbia.edu>
List: tech-security
Date: 01/26/2006 13:21:51
In message <23106.1138285513@sandelman.ottawa.on.ca>, Michael Richardson writes
:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>>>>> "Elad" == Elad Efrat <elad@NetBSD.org> writes:
>    Elad> Here's an idea I was discussing with a friend the other day...
>
>    Elad> Because securelevels start to have too many affects, we could
>    Elad> have the knobs separated, and continue to use kern.securelevel
>    Elad> as a macro.
>
>  I think this is a really cool idea.
>  90% of the things are bits.
>  One of the bits is the right to toggle the bits. 
>  A compile time option could wire the bits in a particular way.
>
>    Elad> So an admin can either go and set kern.securelevel and have
>    Elad> consistent behavior (as it is today), or go and turn on the
>    Elad> knobs he's interested; having a bit of securelevel 2, 1, and
>    Elad> -1.
>
>  Very useful when you want to debug things. 
>  Also very useful if you want to determine how the system might defend
>against various intrusions.
>
>    Elad> The knobs could all be raise-only (just like kern.securelevel
>    Elad> itself).
>
>  I suggest that a COMPILE TIME bit determines this

In principle, this is a fine idea.  In practice, figuring out the right 
set of bits is non-trivial.  It's not a direct analogy, but SGI has 48 
different privileges that a process can have.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb