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