I didn't comment on it, because I don't see this as something that needs
all that much commenting, it only needs some kind of implementation. I can
think of many different versions, I don't know which one is necessarily
the best.
One option is to require that in order to get into X on a machine that has
the securelevel set, the machine has to be booted into X (using xdm or
whatever session manager you want to then use). Then X would get the
appropriate privileges, and after X has started you "shut the door". I
don't like that approach, but hey, I wouldn't be the one using securelevel
anyway.
The way I'd personally probably prefer (but I don't have very strong
feelings about this) is to get rid of the old securelevel altogether,
because it isn't very good. Use bitmaps of capabilities instead, and have
an extension of the "suid" bit which is a "set-capability" binary.
In that kind of secure environment the only thing having the "iopl"
capability would be the X graphics setup binary, and nothing would have
the capability to add any new "set-capabilities" (actually, even that
should probably be a bitmask - the bitmask of which capabilities you can
add to programs).
The whole concept of "securelevel" was brought about for no other reason
than that "root" was too strong, and capabilities are fairly obviously the
way to go. At least _technically_ obviously, I'm worried about the
complexity and maintenance part of it - people are having problems even
maintaining a reasonably "setuid root" environment, I despair about doing
a full capability-based thing (I'm sure good MIS can handle it, but
there's an awful lot of "mediocre" and "bad" MIS out there too).
Security is complex, no doubt about it. But the X server is not really all
that special in this case: the X server happens to need a very specific
kind of service, but that service is not any more security critical than
access to the physical disk, for example (or the permission to load a
kernel loadable module, for example).
Security is not about denying things: I don't think it is necessarily a
good idea to not allow loadable kernel modules in a very secure system,
for example. Security is all about authentication: you must be able to
load only _trusted_ kernel modules, and similarly you must be able to give
iopl privileges only to _trusted_ binaries.
So yes, the X server really implies a certain amount of trust. But you
trust other binaries on the system - "getty", "login", "inetd", "lpr" etc
etc. I'm saying that the X server is really in no way unique here. And
graphics (and X) _is_ so important that I don't see the problem with
having a trusted X server.
I wholly agree that the X server currently has unnecessary levels of
trust: it is one large server that does everything, and as such it is hard
to validate. But the same is true of sendmail - there are other mailers
out there that try to do a better job at not exposing the whole mailer to
being "setuid root", only very small parts. They didn't require kernel
help for that.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu