Douglas Wade Needham wrote:

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

where is the code you're referring to? please refrain from comments
like this because you haven't seen the code. there will be no change
of performance impact for testing whether a certain operation is
allowed or not.

> 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).

what the hell are you talking about? again, the base for your
assumptions is *wrong*.

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

next time i'll remember to cc you privately before anything i commit.
here's a newsflash: options(4) and lots of other things are nothing
but... conditional compilation code.

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

no, it is not; you are just seeing things very very very wrong
and assuming things. please take this FUD elsewhere.

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

kern.securelevel sucks. the security in 4.4bsd sucks. kvm(3) sucks.
*YOU* stick to them.

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

oh wow

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

you're absolutely right; bsd has such a secure reputation because of
securelevel.... not.

-e.

-- 
Elad Efrat