Messages in this thread | | | Date | Sat, 19 Feb 2000 23:38:42 +0100 | From | Pavel Machek <> | Subject | Re: Capabilities |
| |
Hi!
> 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! > > 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
I know I should not touch POSIX semantics.
But you did not understand me well. I wanted to keep allowed bits in filesystem and keep special semantics of uid 0.
> The problem with making a program setuid root, and then trusting > the program to drop the capabilities, is exactly that. You have to
No. Because I would keep allowed set in filesystem. So if it is setuid 0 but allowed set is NET_BIND_LOW, I *know* that it will drop all but NET_BIND_LOW. You see?
> 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
BTW you could also attach proofs that it will correctly drop privileges (:-) or use elfcap trick. It actually provides lscap...
> 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.
You are right that my approach will not give you ability to get away with nonzero uid. That's the point where elfcap got ugly: if you wanted it setuid smtp and forced NET_BIND_LOW, where do you put old uid with my approach.
> 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
I'd like to see elfcap in kernel ;-). That gives verifiable way to know that process drops its capabilities.
> 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.
No. We still miss enforcible allowed set. I wanted to keep allowed set but forget about forced. My idea brings something new (verifyable way to see process drops rights). This idea is better than elfcap because it also works for scripts (not big advantage). And it gets ugly with raised but setuid to different users... So you are partly right...
Pavel -- I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents me at discuss@linmodems.org
- 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/
| |