version=3.0.3
Sender: tech-security-owner@NetBSD.org

Quoting Elad Efrat (elad@NetBSD.org):
> Steven M. Bellovin wrote:
> 
> > The hard part is figuring out what all these different 
> > bits should be, especially if you want them orthogonal.  I cited the 
> > SGI example to show just how many different things you might want to 
> > lock down.
> 
> if securelevel N does x, y, z; then we make new knobs for x, y, z.
> these knobs are raise-only, like securelevel. when you raise
> securelevel, you get all its affects -- so the changes don't hurt
> any existing configurations/uses.

I hope folks don't take this wrong, but I see this as potentially
opening a can of very nasty worms (of the fishing kind).  If we did
such a thing, we would have to test against not only kern.securelevel,
but the knob for x, y or z.  Worse, in some situations, we may find
that have to test against several of these new knobs because of the
mapping of x, y and z.  Then, down the line somewhere, somebody could
forget to check against the global knob, it gets missed in review, and
eventually finds itself into a release where some poor sysadmin just
sets kern.securelevel thinking he is safe, only to find out that he is
not the hard way.  If he is lucky, it is not on a production server,
and he does not loose his job (or loose the argument that they should
move to Windoze, Linux, Solaris, or what ever other platform is in
favor by the PTB).

> of course we can always make it a compile-time option whether we
> want to go the securelevels-route, lots-of-knobs-route, or the
> above described hybrid-route.

Gack!  I can just see the code...just the type of conditional
compilation code I hate to see when I am trying to track down a
problem, and am almost certain to find contains my bug.

> also, as michael richardson suggested, the raise-only part (that
> resembles today's behavior, and i think should be the default) could
> also be set via a compile-time option, making these knobs always
> modifiable.

Again, this is just opening the door to some problem down the line.


My experience going back to before BSD 4.4 day 0 (including being the
person responsible for BSD at CompuServe way back when when we picked
up a release based on the official BSD 4.4 code base) says to follow
the KISS principle on this one.  This means we should stick with just
kern.securelevel, as it has existed since Mike, Kirk and Keith put it
into what became 4.4.  No additional sysctl knobs and no adding in some
compile-time option which allows for it to be decreased.

BTW...in every single one of those BSD servers at CSI, we had
kern.securelevel at a minimum of 1 for all non-development servers,
and it never really caused us problems when debugging things like suid
apps.  Indeed, as one of the folks who was routinely testing our
security by trying to break into machines, there were a number of
times that this is all that stood between the ultimate goal of
undetected access with few if any traces.  Given the hundreds of apps
on the 1500+ servers, I think that is saying quite a bit.

- Doug

-- 
Douglas Wade Needham - KA8ZRT        UN*X Consultant & UW/BSD kernel programmer
Email:  cinnion @ ka8zrt . com       http://cinnion.ka8zrt.com
Disclaimer: My opinions are my own.  Since I don't want them, why
            should my employer, or anybody else for that matter!