Subject: Re: The reason for securelevel (was: sysctl knob to let sugid processes dump core (pr 15994))
To: Michael Richardson <firstname.lastname@example.org>
From: Steven M. Bellovin <email@example.com>
Date: 01/26/2006 13:21:51
In message <firstname.lastname@example.org>, Michael Richardson writes
>-----BEGIN PGP SIGNED MESSAGE-----
>>>>>> "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