> > No amount of immutable bits will save us from this one - these
 > > daemons can't become active until securelevel is set to 1.
 > 
 > Isn't this something you could relatively easily fix with a call
 > to "sysctl -w kern.securelevel=1" placed at the appropriate spot
 > in the startup process?

Sounds good to me.

I think the point remains - until all these steps necessary to make the
assumptions underpinning securelevel 1 valid have been well considered and
documented for interested sys-admins, perhaps the default should be to set
securelevel to -1 to avoid an unfortunate misunderstanding.

I'm going to go out on a limb and guess that the main purpose of the
securelevel feature in 4.4BSD was to provide the hook to allow playing with
the implementation of immutable and append-only features in the filesystem,
rather than as a holistic effort to actually make the whole system more
secure.

My main interest in securelevel is to be able to turn the darn thing off
easily so that I can do user-level device driver work.  This was slightly
inconvenient under NetBSD 1.0, but 1.1's "options INSECURE" does the trick,
though I object to the implication. :-)

Jaime
..............................................................................
:  James da Silva  :  UMCP Computer Science Dept  :  Stand on my shoulders,  :
:  jds@cs.umd.edu  :  http://www.cs.umd.edu/~jds  :  not on my toes.         :