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-kern
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