> How about the fact that in order to do pure capability systems, you'd
> have to rev the interface of every single system call to take a
> capability argument (just as file I/O syscalls now take a file
> descriptor)?
An example use of such a basic and primitive extension would be that a
suid program can throw away its authority to execve() system call, if it
doesn't need it.
Huh? That's hardly a pure-capability system. In a pure capaibility
system, you have something that is effectively like a "key", which can
get passed around between processes, and a privileged program is merely
a program that has several keys that confer more abilities than the
standard default capability.
Using the lock/key anaology, though, having a key doesn't mean that when
I walk towards a locked door (with a bad guy following behind) that the door
will automatically open. I have to explicitly take out the key
(capability) insert it into the lock (pass the capaibility to the
Trusted Code Base) and use the key before it does any good.
This is the argument for why pure capability systems are better, because
it means that it's much harder to trick a privileged program into doing
something it shouldn't during its course of routine operations, since
(for example) it would pass a highly privileged capability to the
creat() system call when creating a temporary file in /tmp. This
instantly eliminates entire classes of security holes. It also makes
the system completely unlike Unix. (And of course, capabilities still
don't help you you against stack overrun attacks.)
Your scheme of simply throwing away authority is something that you can
do using the POSIX capaibility system, and in fact you can do it today
with the current 2.1.x system.
In any case, Alexandar Kjeldaas pointed out (and I completely agree with
him), system calls are completely the wrong level of granularity for
capabilities. Execve() is perhaps the only system call where it might
be interesting, and even there, you might want the ability to exec a
non-privileged process, but not a privileged one. Throwing away the
ability to open any file is almost certainly not going to be useful, but
restricting the ability to bypass the normal permissions checks while
opening files would be useful.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu