lkml.org 
[lkml]   [2009]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2009-12-31 22:49    [W:0.531 / U:0.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site