Re: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs

On Fri, Jan 13, 2012 at 10:24 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> This still appears to be a bit broken
>
> There are three problems here
>
> 1. I can stop an app changing privs which in some SELinux or APParmour
> cases might mean I prevent it being dropped into a less privileged
> position. That's something only the security policy knows.
>
> So for SELinux and Apparmour and the like in some situations you are
> potentially adding a security hole. That one seems hard to fix unless you
> fail the exec if it causes a security transition, as opposed to just
> keeping the old one. For non change cases we can however still pass the
> filter on, which is the usual sane case.

SELinux can already control this via exec_no_trans.

Changing it to fail the exec when a transition would occur will make
seccomp considerably less useful to selinux users -- the presence of
MAC policy on a program (regardless of what that policy is) will make
it unusable inside a sandbox.

<rant>This is exactly why I think that changing security context on
execve() is an awful idea.  If administrators and distros want to
define fancy contexts, fine.  But programs should *ask* to enter the
contexts.  (This would be easy enough with some glibc / libselinux
magic.)  And the use of MAC should not prevent the use of IMO
considerably more secure user-controlled sandbox technologies.
execve_nosecurity was my first attempt to fix it without hitting this
issue.</rant>

>
> 2. ptrace
>
> You neeed to also stop ptrace otherwise the locked down process can use
> ptrace to proxy its activity via another task with the same uid. That's
> easy enough to add fortunately.
>
> 3. file access
>
> You have the same attacks via patching files of running apps etc. In the
> intended circumstances I'm not sure this matters or is cleanly fixable.
> It's the point at which you need a real system wide policy and SELinux
> etc anyway.

I disagree, but maybe this is a sign that no_new_privs is a bad name.
no_new_privs is not intended to be a sandbox at all -- it's a way to
make it safe for a task to manipulate itself in a way that would allow
it to subvert its own children (or itself after execve).  So ptrace
isn't a problem at all -- PR_SET_NO_NEW_PRIVS + chroot + ptrace is
exactly as unsafe as ptrace without PR_SET_NO_NEW_PRIVS.  Neither one
allows privilege escalation beyond what you started with.

If you want a sandbox, call PR_SET_NO_NEW_PRIVS, then enable seccomp
(or whatever) to disable ptrace, evil file access, connections on unix
sockets that authenticate via uid, etc.  (IMO MAC has no place here --
maybe we need a new buzzword like "Voluntary Access Control".)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html