> 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 capaibilitysystem, you have something that is effectively like a "key", which canget passed around between processes, and a privileged program is merelya program that has several keys that confer more abilities than thestandard default capability.

Using the lock/key anaology, though, having a key doesn't mean that whenI walk towards a locked door (with a bad guy following behind) that the doorwill automatically open. I have to explicitly take out the key(capability) insert it into the lock (pass the capaibility to theTrusted Code Base) and use the key before it does any good.

This is the argument for why pure capability systems are better, becauseit means that it's much harder to trick a privileged program into doingsomething it shouldn't during its course of routine operations, since(for example) it would pass a highly privileged capability to thecreat() system call when creating a temporary file in /tmp. Thisinstantly eliminates entire classes of security holes. It also makesthe system completely unlike Unix. (And of course, capabilities stilldon't help you you against stack overrun attacks.)

Your scheme of simply throwing away authority is something that you cando using the POSIX capaibility system, and in fact you can do it todaywith the current 2.1.x system.

In any case, Alexandar Kjeldaas pointed out (and I completely agree withhim), system calls are completely the wrong level of granularity forcapabilities. Execve() is perhaps the only system call where it mightbe interesting, and even there, you might want the ability to exec anon-privileged process, but not a privileged one. Throwing away theability to open any file is almost certainly not going to be useful, butrestricting the ability to bypass the normal permissions checks whileopening files would be useful.

- Ted

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.edu