From: Eric Paris <eparis@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Oleg Nesterov <oleg@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
Will Drewry <wad@chromium.org>,
torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
keescook@chromium.org, john.johansen@canonical.com,
serge.hallyn@canonical.com, coreyb@linux.vnet.ibm.com,
pmoore@redhat.com, djm@mindrot.org, segoon@openwall.com,
rostedt@goodmis.org, jmorris@namei.org, scarybeasts@gmail.com,
avi@redhat.com, penberg@cs.helsinki.fi, viro@zeniv.linux.org.uk,
luto@MIT.EDU, mingo@elte.hu, akpm@linux-foundation.org,
khilman@ti.com, borislav.petkov@amd.com, amwang@redhat.com,
ak@linux.intel.com, eric.dumazet@gmail.com, gregkh@suse.de,
dhowells@redhat.com, daniel.lezcano@free.fr,
linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, olofj@chromium.org,
mhalcrow@google.com, dlaor@redhat.com, corbet@lwn.net
Subject: Re: [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
Date: Fri, 13 Jan 2012 13:54:51 -0500 [thread overview]
Message-ID: <1326480891.4342.7.camel@localhost> (raw)
In-Reply-To: <20120113182422.28e648fb@pyramind.ukuu.org.uk>
On Fri, 2012-01-13 at 18:24 +0000, Alan Cox 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.
I can't speak about AppArmour at all, but not transitioning in SELinux
(the same as MNT_NOSUID) is safe since policy will still make a security
decision if you are allowed to launch the binary without transitioning.
I have thoughts on how to make the SELinux approach more flexible and
policy controlled, but I'd be fine with this flag just applying no
transition for now and adding that as a new feature down the road.
next prev parent reply other threads:[~2012-01-13 18:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-13 2:12 [PATCH] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs Andy Lutomirski
2012-01-13 5:58 ` Kees Cook
2012-01-13 6:02 ` Andy Lutomirski
2012-01-13 6:09 ` Kees Cook
2012-01-13 7:27 ` John Johansen
2012-01-13 13:45 ` John Johansen
2012-01-13 16:45 ` Oleg Nesterov
2012-01-13 18:24 ` Alan Cox
2012-01-13 18:54 ` Eric Paris [this message]
2012-01-13 19:00 ` Andy Lutomirski
2012-01-13 19:12 ` Linus Torvalds
2012-01-13 19:39 ` Andy Lutomirski
2012-01-13 19:45 ` Linus Torvalds
2012-01-13 20:05 ` Andy Lutomirski
2012-01-13 20:13 ` Linus Torvalds
2012-01-13 20:19 ` Andy Lutomirski
2012-01-13 20:13 ` Eric Paris
2012-01-13 21:13 ` Linus Torvalds
2012-01-14 13:55 ` Jamie Lokier
2012-01-17 23:57 ` Eric W. Biederman
2012-01-18 0:22 ` Andy Lutomirski
-- strict thread matches above, loose matches on Subject: below --
2012-01-14 15:17 Eric Paris
2012-01-14 16:04 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1326480891.4342.7.camel@localhost \
--to=eparis@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=amwang@redhat.com \
--cc=avi@redhat.com \
--cc=borislav.petkov@amd.com \
--cc=corbet@lwn.net \
--cc=coreyb@linux.vnet.ibm.com \
--cc=daniel.lezcano@free.fr \
--cc=dhowells@redhat.com \
--cc=djm@mindrot.org \
--cc=dlaor@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=gregkh@suse.de \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=khilman@ti.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@MIT.EDU \
--cc=luto@amacapital.net \
--cc=mhalcrow@google.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
--cc=olofj@chromium.org \
--cc=penberg@cs.helsinki.fi \
--cc=pmoore@redhat.com \
--cc=rostedt@goodmis.org \
--cc=scarybeasts@gmail.com \
--cc=segoon@openwall.com \
--cc=serge.hallyn@canonical.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).