[systemd-devel] [PATCH 1/2] Add detect_userns to detect uid/gid shifts

[Djalal Harouni]

On Thu, Jan 08, 2015 at 09:25:07PM +0100, Tom Gundersen wrote:
> On Thu, Jan 8, 2015 at 8:59 PM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> > On Thu, Jan 08, 2015 at 08:43:12PM +0100, Tom Gundersen wrote:
> >> On Thu, Jan 8, 2015 at 8:27 PM, Stéphane Graber <stgraber at ubuntu.com> wrote:
> >> > +        /* If both uid_map and gid_map don't exist or if they both match
> >> > +         * the full uid/gid range, then we're not inside a user namespace */
> >>
> >> Hm, this is not necessarily true is it? In my naive test, it works
> >> just fine to set up a usernamespace with the identity mapping.
> >> Moreover, this appears to be functionally different from the initial
> >> user namespaces (somewhat counter-intuitively I might add), so
> >> treating the identity mapping as 'no user namespace' is probably not
> >> the right thing to do.
> >>
> >> Is there no better way to test for this?
> >
> > I'm not sure I understand what you mean there.
> >
> > When you unshare CLONE_NEWUSER, your uid_map and gid_map are empty. You
> > can then write a map using your own uid and gid or use a privileged
> > helper to write a larger map.
> >
> > The only case where you could be in a separate user namespace and still
> > have the same map as the host is if you had a privileged helper write
> > the whole host uid and gid map to your process' uid_map and gid_map, in
> > which case, your process' uid 0 is mapped to the host uid 0
> 
> Yeah, I'm looking at privileged user namespaces, so you are setting
> them up as root (which I understand is different from your usecase
> where you want to do this as a regular user).
> 
> To be clear, I used Michael Kerrisk's test tool [0] like this (as root):
> 
> # ./userns_child_exec -U -M '0 0 4294967295' -G '0 0 4294967295' bash
> 
> > and while
> > you are technically in a different namespace than the host, your
> > accesses are identical and so it's not unreasonable to have
> > detect_userns report this as the host namespace.
> 
> It appears to me that this ("your accesses are identical") is not true
> though. At least I found mknod(8) and mount(8) to work on the host,
> but not in the identity-mapped user namespace [1]. Had it been true, I
> would agree with you that we should just treat this the same as not
> being in a user namespace, but as this is not the case (or I'm doing
> something wrong in my test) we may want to be careful here.
>
> Obviously, the identity-mapped user namespace does not sound at all
> useful to me, so maybe we can ignore it (if there really is no other
> way), but we should document that at least.
> 
> Cheers,
Hmm Tom a quick glance suggest that at least you need a new mount
namespace, IOW you have to own the mount namespace before mounting
stuff there...

So from that tool if you add -m then you should be able at least to
mount tmpfs in test/

For mknode, I remember that there was something special or a security
bug that perhaps forces nodev... (not sure)

And yes we have to be careful, that's definitely not the same thing, you
may have some capabilities set but still some operations are and should
be restricted like _arbitrary_ modules loading... another thing, only a
limited number of filesystems can be mounted from a user namespace,
major ones do not support this...


> Tom
> 
> [0]: <lwn.net/Articles/539940/>
> [1]:
> 
> [root at tomegun-x240 userns]# ./userns_child_exec -U -M '0 0 4294967295'
> -G '0 0 4294967295' bash
> [root at tomegun-x240 userns]# mknod null b 1 3
> mknod: ‘null’: Operation not permitted
> [root at tomegun-x240 userns]# mount -t tmpfs none test/
> mount: permission denied
> [root at tomegun-x240 userns]# exit
> exit
> [root at tomegun-x240 userns]# mknod null b 1 3
> [root at tomegun-x240 userns]# mount -t tmpfs none test/
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

-- 
Djalal Harouni
http://opendz.org