Messages in this thread |  | | | From | Andy Lutomirski <> | | Date | Mon, 16 Jan 2012 13:25:42 -0800 | | Subject | Re: [PATCH v2 0/4] PR_SET_NO_NEW_PRIVS, unshare, and chroot |
| |
On Mon, Jan 16, 2012 at 12:49 PM, Colin Walters <walters@verbum.org> wrote: > 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.
The MS_NOSUID semantics are somewhat ridiculous for selinux, and I'd rather not make them match for no_new_privs. AppArmor completely ignores MS_NOSUID, so I think the rename would just cause more confusion.
> > 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.
That would just make it more complicated. The race is already solved in the current patch, anyway.
> >> 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?
CLONE_NEWNET seems more likely to consume significant kernel resources than the others. 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.
> > 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. > >
Fair enough. I may add this in v3. seccomp is an even better solution, though :)
--Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |