Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 13 Jan 2012 11:00:51 -0800 | Subject | 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
| |