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

[Stéphane Graber]

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,
> 
> Tom

Hmm, indeed, looking at the kernel code, mknod and mount are restricted
even if the container's uid 0 is mapped to real uid 0.

As far as I know there's no obvious way to detect this case (well, short
of trying a bunch of restricted syscalls). The only way I'm aware of is
by comparing the target of /proc/self/ns/user to that of /proc/<real
host pid 1>/ns/user which is doable at the host level but isn't once you
are in a container with your own pid namespace (which since we're
talking about pid 1 systemd there can probably be assumed).

> 
> [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/

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150108/0b716b4c/attachment.sig>