From: Colin Walters <walters@verbum.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jamie Lokier <jamie@shareable.org>,
Will Drewry <wad@chromium.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, eparis@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, mingo@elte.hu,
akpm@linux-foundation.org, khilman@ti.com,
borislav.petkov@amd.com, amwang@redhat.com, oleg@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,
alan@lxorguk
Subject: Re: [PATCH v2 0/4] PR_SET_NO_NEW_PRIVS, unshare, and chroot
Date: Mon, 16 Jan 2012 15:49:07 -0500 [thread overview]
Message-ID: <1326746949.3467.16.camel@lenny> (raw)
In-Reply-To: <cover.1326673414.git.luto@amacapital.net>
On Sun, 2012-01-15 at 16:37 -0800, Andy Lutomirski wrote:
> To make the no_new_privs discussion more concrete, here is an updated
> series that is actually useful. It adds PR_SET_NO_NEW_PRIVS
I think it'd be clearer to call it PR_SET_NOSUID - basically it should
match the semantics for MS_NOSUID mounts, as if on every exec()
thereafter the target binary was on a nosuid filesystem.
You might then change this flag to only take effect on a later exec(),
which would solve your race condition for the hypothetical PAM module.
> with the
> same semantics as before (plus John Johansen's AppArmor fix and with
> improved bisectability). It then allows some unshare flags
What's the rationale behind the unshare subset? Did you actually
analyze any setuid binaries found on Debian/Fedora etc. and determined
that e.g. CLONE_NEWNET was problematic for some reason?
I actually want CLONE_NEWNET for my build tool, so I can be sure the
arbitrary code I'm executing as part of the build at least isn't
downloading more new code.
WARNING: multiple messages have this Message-ID (diff)
From: Colin Walters <walters@verbum.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Jamie Lokier <jamie@shareable.org>,
Will Drewry <wad@chromium.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, eparis@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, mingo@elte.hu,
akpm@linux-foundation.org, khilman@ti.com,
borislav.petkov@amd.com, amwang@redhat.com, oleg@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,
alan@lxorguk.ukuu.org.uk
Subject: Re: [PATCH v2 0/4] PR_SET_NO_NEW_PRIVS, unshare, and chroot
Date: Mon, 16 Jan 2012 15:49:07 -0500 [thread overview]
Message-ID: <1326746949.3467.16.camel@lenny> (raw)
In-Reply-To: <cover.1326673414.git.luto@amacapital.net>
On Sun, 2012-01-15 at 16:37 -0800, Andy Lutomirski wrote:
> To make the no_new_privs discussion more concrete, here is an updated
> series that is actually useful. It adds PR_SET_NO_NEW_PRIVS
I think it'd be clearer to call it PR_SET_NOSUID - basically it should
match the semantics for MS_NOSUID mounts, as if on every exec()
thereafter the target binary was on a nosuid filesystem.
You might then change this flag to only take effect on a later exec(),
which would solve your race condition for the hypothetical PAM module.
> with the
> same semantics as before (plus John Johansen's AppArmor fix and with
> improved bisectability). It then allows some unshare flags
What's the rationale behind the unshare subset? Did you actually
analyze any setuid binaries found on Debian/Fedora etc. and determined
that e.g. CLONE_NEWNET was problematic for some reason?
I actually want CLONE_NEWNET for my build tool, so I can be sure the
arbitrary code I'm executing as part of the build at least isn't
downloading more new code.
next prev parent reply other threads:[~2012-01-16 20:49 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-16 0:37 [PATCH v2 0/4] PR_SET_NO_NEW_PRIVS, unshare, and chroot Andy Lutomirski
2012-01-16 0:37 ` [PATCH v2 1/4] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs Andy Lutomirski
2012-01-16 17:33 ` Oleg Nesterov
2012-01-16 20:15 ` Andy Lutomirski
2012-01-16 20:15 ` Andy Lutomirski
2012-01-16 0:37 ` [PATCH v2 2/4] Fix apparmor for PR_{GET,SET}_NO_NEW_PRIVS Andy Lutomirski
2012-01-16 0:37 ` [PATCH v2 3/4] Allow unprivileged CLONE_NEWUTS and CLONE_NEWIPC with no_new_privs Andy Lutomirski
2012-01-16 0:37 ` [PATCH 4/4] Allow unprivileged chroot when safe Andy Lutomirski
2012-01-16 0:45 ` Linus Torvalds
2012-01-16 0:45 ` Linus Torvalds
2012-01-16 1:08 ` Andy Lutomirski
2012-01-16 1:08 ` Andy Lutomirski
2012-01-16 19:26 ` Colin Walters
2012-01-16 19:26 ` Colin Walters
2012-01-16 20:18 ` Andy Lutomirski
2012-01-16 20:18 ` Andy Lutomirski
2012-01-17 10:14 ` Jamie Lokier
2012-01-17 10:14 ` Jamie Lokier
2012-01-16 20:06 ` Al Viro
2012-01-16 20:15 ` Andy Lutomirski
2012-01-16 20:26 ` Al Viro
2012-01-17 16:23 ` Oleg Nesterov
2012-01-17 16:31 ` Andy Lutomirski
2012-01-16 1:04 ` [PATCH v2 0/4] PR_SET_NO_NEW_PRIVS, unshare, and chroot Andy Lutomirski
2012-01-16 1:04 ` Andy Lutomirski
2012-01-16 20:49 ` Colin Walters [this message]
2012-01-16 20:49 ` Colin Walters
2012-01-16 21:25 ` Andy Lutomirski
2012-01-16 21:25 ` Andy Lutomirski
2012-01-16 21:47 ` Colin Walters
2012-01-16 21:47 ` Colin Walters
2012-01-16 21:57 ` Andy Lutomirski
2012-01-16 21:57 ` 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=1326746949.3467.16.camel@lenny \
--to=walters@verbum.org \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk \
--cc=amwang@redhat.com \
--cc=avi@redhat.com \
--cc=borislav.petkov@amd.com \
--cc=casey@schaufler-ca.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=eparis@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=gregkh@suse.de \
--cc=jamie@shareable.org \
--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@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.