linux-kernel - Re: 3.0: user namespace problem with capabilities

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 21 Jul 2011 08:40:25 -0500
From:	"Serge E. Hallyn" <serge.hallyn@...onical.com>
To:	Arkadiusz Miskiewicz <a.miskiewicz@...il.com>
Cc:	linux-kernel@...r.kernel.org, Herbert Poetzl <herbert@...hfloor.at>
Subject: Re: 3.0: user namespace problem with capabilities

Quoting Arkadiusz Miskiewicz (a.miskiewicz@...il.com):
> 
> Hi,
> 
> linux-vserver guys think that there is a problem with user namespace in 
> upcoming 3.0
> 
> "this is a mainline/upstream bug, which basically happens
> when unsharing the USER namespace. what happens is that
> all capabilities are dropped, and as result, the userspace
> tool cannot issue Linux-VServer syscall commands anymore
> (because of missing CAP_CONTEXT)"
> 
> "this can be verified on vanilla linux-3.0 kernels with
> http://vserver.13thfloor.at/Stuff/clone_newuser.c
> in the following way:
> 
> gcc -o clone_newuser clone_newuser.c
> ./clone_newuser ls /root/
> 
> assuming that /root does not have any right for 'other'
> this will result in a permission denied (when the USER
> namespace is compiled into the kernel)"
> 
> Whole post:
> 
> http://list.linux-vserver.org/archive?msp:5151:ekldgndhkgmehnehiegi
> 
> What's maintainers opinion on this?

See http://wiki.ubuntu.com/UserNamespace for details on what's
going on.  See the recent patchset at https://lkml.org/lkml/2011/7/12/377
to see (and help speed up) the next steps.  After that patchset, I
need to address passing userids in siginfos and other uid comparisons,
and then, at least, comes VFS support.  The speed with which it can be
completed depends in part upon my time, and largely on the amount
of time reviewers have.  This stuff is obviously highly critical
security-relevant code, and needs to be very well reviewed and tested
at each step.

(See also http://forum.openvz.org/index.php?t=msg&th=9374&goto=41543&#msg_41543
for the email I sent to containers@, libvirt@, and other lists before
beginning to solicit NACKs in advance)

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/