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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:24 EST