Messages in this thread |  | | | Date | Sun, 26 Apr 1998 16:39:25 -0400 | | From | "Theodore Y. Ts'o" <> | | Subject | Re: [patch 2.1.97] more capabilities support |
| |
Date: Sun, 26 Apr 1998 01:27:11 +0200 From: Andrej Presern <andrejp@luz.fe.uni-lj.si>
> 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
|  |