Messages in this thread | | | Date | Thu, 31 Dec 2009 15:46:21 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: [RFC][PATCH v3] Unprivileged: Disable raising of privileges |
| |
Quoting Eric W. Biederman (ebiederm@xmission.com): > "Andrew G. Morgan" <morgan@kernel.org> writes: > > > Since there is already independent support for disabling file > > capabilities (the privilege escalation part), I see these two > > mechanisms as separable. > > I guess there is something that resembles support for disabling > privilege escalation. The problem is that it requires privilege to > use it. > > I have no problem with expressing this in a fine grained manner internally > to the kernel but the user space interface needs to be atomic so that > we can enable this all without privilege. > > Further I may be off but I think the implementation would be more > challenging than what I have already posted. That doesn't mean it > won't be more useful long term. > > Eric
Right, what we can currently do with capabilities is:
1. drop capabilities from the bounding set. This is privileged because it is fine-grained, and can trick capability-unaware privileged programs. 2. drop CAP_SETUID from pP, pI, and the bounding set, to prevent any future setuids. Privileged for the same reason as 1. 3. set SECURE_NOROOT and SECURE_NOSUIDFIXUP, so that uid 0 won't automatically get privileges.
It doesn't provide a way for stopping setuid on setuid binaries, though, and as we've previously noted, while we'd *like* to say that uids and privileges can be treated separately, in reality the unprivileged root user still owns most of the system. So we should also provide the per-task nosuid bit, meaning do not change uid for a setuid binary. This could be treated as another securebit,
SECURE_NOSUID
So if the capabilities module supports a special prctl(PR_SET_NOSUID) which at the same time completely empties pP, pE, pI, and the bounding set, and sets the SECURE_NOSUID securebit, that should be safe for an unprivileged user. (There is no need for SECURE_NOROOT and SECURE_NOSUIDFIXUP in that case obviously).
Or, it could set SECURE_NOSUID|SECURE_NOROOT|SECURE_NOSUID_FIXUP (and the corresponding _LOCKED bits).
-serge
| |