All of lore.kernel.org
 help / color / mirror / Atom feed
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 16:47:00 -0500	[thread overview]
Message-ID: <1326750422.3467.31.camel@lenny> (raw)
In-Reply-To: <CALCETrW3WyzaGBMJZzfohD=MRwdmeV9bAo4Leg1gaSnPL5URpg@mail.gmail.com>

On Mon, 2012-01-16 at 13:25 -0800, Andy Lutomirski wrote:

> The MS_NOSUID semantics are somewhat ridiculous for selinux, 

I don't see how they're ridiculous.

> and I'd
> rather not make them match for no_new_privs. 

Note your patch for selinux does exactly the same thing in the NOSUID
case and your NO_NEW_PRIVS flag.  Right?

-       if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
+       if ((bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID) ||
+           (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))
                new_tsec->sid = old_tsec->sid;


>  AppArmor completely
> ignores MS_NOSUID,

Ugh...well, I guess if it doesn't store any security data associated
with files, only with file names, then there's nothing for it to do.
Like I said before though, I think SELinux is the only sane LSM.

> CLONE_NEWNET seems more likely to consume significant kernel resources
> than the others. 

This actually brings up something we need to think about - if we're
heading towards being able to do bind mounts as non-root (which is
necessary for me) we'd need limits on e.g. the number of mounts that can
be made for a given uid/cgroup.

I have a picked-from-thin-air hardcoded limit of 50 in my setuid binary,
but I just realized that that's 50*RLIMIT_NPROC which is kind of
large...

>  I didn't have a great reason, though.  Unsharing the
> filesystem namespace is possibly dangerous because it could prevent an
> unmount in the original namespace from taking effect everywhere.

Hmmm...hadn't considered that either.  So the issue here is if a server
admin has e.g. a NFS mount and my build tool makes a new copy of the
mount namespace, a process may still have it busy when she goes to
unmount it?

> Fair enough.  I may add this in v3.  seccomp is an even better
> solution, though :)

Yeah, definitely more flexible, though realistic use of seccomp depends
on someone making a nice userspace tool to compile sets of syscalls like
"no networking".


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 16:47:00 -0500	[thread overview]
Message-ID: <1326750422.3467.31.camel@lenny> (raw)
In-Reply-To: <CALCETrW3WyzaGBMJZzfohD=MRwdmeV9bAo4Leg1gaSnPL5URpg@mail.gmail.com>

On Mon, 2012-01-16 at 13:25 -0800, Andy Lutomirski wrote:

> The MS_NOSUID semantics are somewhat ridiculous for selinux, 

I don't see how they're ridiculous.

> and I'd
> rather not make them match for no_new_privs. 

Note your patch for selinux does exactly the same thing in the NOSUID
case and your NO_NEW_PRIVS flag.  Right?

-       if (bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID)
+       if ((bprm->file->f_path.mnt->mnt_flags & MNT_NOSUID) ||
+           (bprm->unsafe & LSM_UNSAFE_NO_NEW_PRIVS))
                new_tsec->sid = old_tsec->sid;


>  AppArmor completely
> ignores MS_NOSUID,

Ugh...well, I guess if it doesn't store any security data associated
with files, only with file names, then there's nothing for it to do.
Like I said before though, I think SELinux is the only sane LSM.

> CLONE_NEWNET seems more likely to consume significant kernel resources
> than the others. 

This actually brings up something we need to think about - if we're
heading towards being able to do bind mounts as non-root (which is
necessary for me) we'd need limits on e.g. the number of mounts that can
be made for a given uid/cgroup.

I have a picked-from-thin-air hardcoded limit of 50 in my setuid binary,
but I just realized that that's 50*RLIMIT_NPROC which is kind of
large...

>  I didn't have a great reason, though.  Unsharing the
> filesystem namespace is possibly dangerous because it could prevent an
> unmount in the original namespace from taking effect everywhere.

Hmmm...hadn't considered that either.  So the issue here is if a server
admin has e.g. a NFS mount and my build tool makes a new copy of the
mount namespace, a process may still have it busy when she goes to
unmount it?

> Fair enough.  I may add this in v3.  seccomp is an even better
> solution, though :)

Yeah, definitely more flexible, though realistic use of seccomp depends
on someone making a nice userspace tool to compile sets of syscalls like
"no networking".


  reply	other threads:[~2012-01-16 21:47 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
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 [this message]
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=1326750422.3467.31.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.