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


\
 
 \ /
  Last update: 2012-01-13 20:03    [W:0.195 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site