User: Password:
|
|
Subscribe / Log in / New account

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

From:  Andy Lutomirski <luto-AT-amacapital.net>
To:  Alan Cox <alan-AT-lxorguk.ukuu.org.uk>
Subject:  Re: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
Date:  Fri, 13 Jan 2012 11:00:51 -0800
Message-ID:  <CALCETrX_nA4MtjDCKdfwJBOO6QEyzk_6nbr5Ou6QqkXcq2rTPQ@mail.gmail.com>
Cc:  Oleg Nesterov <oleg-AT-redhat.com>, Will Drewry <wad-AT-chromium.org>, torvalds-AT-linux-foundation.org, linux-kernel-AT-vger.kernel.org, keescook-AT-chromium.org, john.johansen-AT-canonical.com, serge.hallyn-AT-canonical.com, coreyb-AT-linux.vnet.ibm.com, pmoore-AT-redhat.com, eparis-AT-redhat.com, djm-AT-mindrot.org, segoon-AT-openwall.com, rostedt-AT-goodmis.org, jmorris-AT-namei.org, scarybeasts-AT-gmail.com, avi-AT-redhat.com, penberg-AT-cs.helsinki.fi, viro-AT-zeniv.linux.org.uk, luto-AT-mit.edu, mingo-AT-elte.hu, akpm-AT-linux-foundation.org, khilman-AT-ti.com, borislav.petkov-AT-amd.com, amwang-AT-redhat.com, ak-AT-linux.intel.com, eric.dumazet-AT-gmail.com, gregkh-AT-suse.de, dhowells-AT-redhat.com, daniel.lezcano-AT-free.fr, linux-fsdevel-AT-vger.kernel.org, linux-security-module-AT-vger.kernel.org, olofj-AT-chromium.org, mhalcrow-AT-google.com, dlaor-AT-redhat.com, corbet-AT-lwn.net
Archive-link:  Article

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



(Log in to post comments)


Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds