Messages in this thread | | | Date | Sat, 19 Feb 2000 14:51:51 -0500 | From | "Theodore Y. Ts'o" <> | Subject | Re: Capabilities |
| |
Date: Fri, 11 Feb 2000 22:35:32 +0100 From: Pavel Machek <pavel@suse.cz>
But you can set allowed to ~0; forced to 0 for normal executables and ~0 to setuid root executables. BTW we should probably make forced set being honoured iff executable is suid root. Pavel PS: When I think of it, there's an easier way. Trash forced set. It is not neccessary.
If you want to elevate some priviledges, make it setuid 0 (that will give it all capabilities) and you can now copy forced into allowed. You are done. You have nice compatibility (ls) for free, and you have 32 more bits for your use!
Pavel,
There are a couple of philosophical questions hiding here. It's true the POSIX capability document never became a full standard, but died as only a draft. However, there are other implementations of that draft, most notably Trusted Irix, and Trusted HPUX. (Trusted Solaris isn't quite as close to the standard, and I don't know about the status of Trusted AIX; I believe it's fairly close to the draft POSIX capability as well.) So the first question is whether we want to try to conform to the last POSIX draft, and (as much as possible) be compatible with the other Trusted Unixes out there.
Secondly, there is a philosophical principal here. Part of the entire Capability model is to adhere to the security principle of least privilege as much as possible. One of things that this means is to drop the idea that user ID 0 has any meaning whatsoever. So in a pure POSIX capability system, a program that is setuid 0 has the ability to have "owner" access to files that are owned by userid 0, but that's it. It means nothing more than that.
The problem with making a program setuid root, and then trusting the program to drop the capabilities, is exactly that. You have to trust the program to do so correctly. That's why the POSIX capability model is done the way that it is done. A system administrator can look at an executable, and know exactly what privileges it can possibly ever use. If it can only create sockets whose port is below 1024, it will be obvious simply by looking at the flags. It also means that a program can be setuid to some non-zero uid, such as "smtp", so it can run as the "smtp" user, but still have access to a (limited) set of capabilities.
Now, with all of that being said, if you don't want the full POSIX model, it's probably easier to simply leave things the way they are right now, and not try to put anything in the filesystem. Just simply allow programs to be setuid root, and then let them drop whatever capabilities they don't need as soon as they start running in main() --- hopefully before any stack overrun vulnerabilities have a chance to execute. :-)
If you're going to restrict capabilities to work iff they are suid root, and if you're only going to trash the forced set and simply allow the program to drop privileges on its own, why make any changes at all? The functionality you propose we can do already, given what we already have.
But if we want to support the full capability model, then we can't take shortcuts like that. As I said earlier, it's very different from the Unix model, and I'm not so convinced that sysadmins will be able to deal with it correctly. If we're going to try to do capabilities, however, we might as well try to do them right.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |