Hi, On Thu, May 05, 2016 at 08:05:08AM -0500, Seth Forshee wrote: > On Wed, May 04, 2016 at 11:19:04PM +0000, Serge Hallyn wrote: > > Quoting Djalal Harouni (tixxdz@xxxxxxxxx): > > > If a process gets access to a mount from a different user > > > namespace, that process should not be able to take advantage of > > > setuid files or selinux entrypoints from that filesystem. Prevent > > > this by treating mounts from other mount namespaces and those not > > > owned by current_user_ns() or an ancestor as nosuid. > > > > > > This patch was just adapted from the original one that was written > > > by Andy Lutomirski <luto@xxxxxxxxxxxxxx> > > > https://www.redhat.com/archives/dm-devel/2016-April/msg00374.html > > > > I'm not sure that this makes sense given what you're doing. In the > > case of Seth's set, a filesystem is mounted specifically (and privately) > > in a user namespace. We don't want for instance the initial user ns > > to find a link to a setuid-root exploit left in the container-mounted > > filesystem. > > > > But you are having a parent user namespace mount the fs so that its > > children can all access the fs, uid-shifted for convenience. Not > > allowing the child namespaces to make use of setuid-root does not > > seem applicable here. > > Right, the problem addressed by this patch probably isn't relevant to > this sort of uid shifting. I'll have another deep look into it, yes the aim when I ported this, is I was not sure about setns(), or if you get a handle to a mount namespace through /proc or anything else... then you call into it from an external user namespace. > But I think there's another problem that needs to be addressed. > bprm_fill_uid() still gets the ids for sxid files unshifted from the > inode. We already protect against sxid to any user not in > bprm->cred->user_ns, so it will just ignore the sxid instead of e.g. > suid as global root from the id shifted mount, which is good. What would > be wanted though is to use the shifted ids so that something like > suid-root ping in the container rootfs would work. > > Seth Ok thank you Seth! I'll note it and try to fix it. -- Djalal Harouni http://opendz.org -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
