> > This still has a _lot_ of
> >
> > "if ((securelevel > 0) || !suser())"
> >
> > things, which is obviously broken.
>
> Why, some things have to be disabled for any security setting to prevent
> the securelevel being raised. Thats the point of BSD securelevel
Sure, that's the point of _BSD_ securelevels, but as we know the BSD
securelevel stuff is stupidly done.
It is _entirely_ reasonable to allow a process access to IO registers even
if the process shouldn't have the permissions to set the securelevel.
Sure, we don't want to give that privilege to a completely untrusted
program, because then the untrusted program could mess with the disk IO
registers directly and change the disk to appear the way they wanted.
But the whole point is that the world is not black-and-white, and not even
shades-of-gray. That's why the BSD securelevel stuff is WRONG. The BSD
securelevel thinks the world can be partitioned up into "complete trust"
and "no trust", which is just not how it works.
It is, btw, exactly the same stupidity that they had wrt interrupt
privilege levels: using shades of gray rather than using bitmaps.
The other stupidity in the BSD stuff is that the securelevel is a global
variable. That is just _wrong_, as it implies that "init" has no more
privileges than any randomly started hacker program.
In short, securelevels should be
(a) bitmaps
(b) per-process
ie a securelevel is really a capability - and if you want to have the
stupid BSD-kind of securelevel you just make init shut down all
capabilities very early, and then those fascist rules will get inherited
by everything else. Doing securelevels the right way does not mean that a
fascist MIS department couldn't force the wrong way on people if they want
to.
So for example, you might chose to have your "guest" account get some very
restrictive secure-levels that don't allow them to do anything you don't
want them to du (not run setuid binaries, for example, much less start up
X etc). But that doesn't mean that you should have a securelevel that
makes the machine unusable for others.
Considering exactly how many truly stupid things the BSD guys have done it
continually makes me surprised how many people still consider their ideas
good without thinking too much about them.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu