On Thu, Jan 26, 2006 at 02:44:29PM -0500, Chapman Flack wrote:
> 
> Please. The stakes are high enough, and the issues thorny enough,
> that even viewpoints other than your own may be valuable in whole
> or in part. What makes this stuff challenging (whether as separate
> knobs or just as a matter of pinning down the proper set of
> operations needing to be conditioned on the single securelevel knob)
> is that they are far from orthogonal in practice. VMS had, IIRC,
> 32 privileges or so, and you could group several of them into a set
> you might as well call "root-complete" because if you had any one
> in the set you could as a SMoP accomplish whatever any of the
> others purportedly controlled.

Indeed.  That's one of my concerns here.  The historical evolution of
this stuff goes kind of like this:

"Let's add a knob to the system that makes it impossible to make persistent
 changes even if you're root, unless you have physical access to the
 hardware."

"Hey, we missed something!  You can still attach a debugger to init and
 yank the security level back down."

"Hey, we missed something else!  You can still access raw disks using
 overlapping partitions."

"Hey, you're never going to believe this, but we missed a couple of
 other things -- like, say, you can remount filesystems read/write
 even when you have the knob turned to 'secure'"...

The intention was to find _all_ the "persistent change complete"
privileges and have securelevel turn them _all_ off.  Unfortunately,
this interacted badly with two other motives: to restrict other
functionality that was dangerous for other reasons so that it was
only available to those who could get at the console, and to not
break existing applications.

The upshot was that a bunch of stuff all got bundled into securelevel 2
that shouldn't have gone together: in particular, privileges that really
needed to be restricted at level 1 were restricted at level 2 instead.

If we're basically going to start from scratch, I think we should keep
the original motivation in mind: to provide a single, simple setting
that disables *all* the privileges that could be used to make changes
to the TCB without console access to the machine.

I tend to believe that it is generally a poor idea to offer the user
too many choices for configuring security software: inevitably, a user
who thinks he understands the underlying issues better than he actually
does will end up with a seriously false sense of security.  Hell, even
purported "experts" mess this up -- look at the holes left in the first
several passes at implementing TCB support via securelevel.  The simplest
and most obvious user interface ought to simply _enforce_ the judgment of
the best experts we can find and thus protect users from their own
overconfidence; tunables for people who know what they're doing, it seems
to me, are the kind of things that should be compiled in by an option.

Thor