Description of problem:
A while back we disabled CONFIG_USER_NS. This reflected the fact that existing user namespace support was essentially fubar
Author: Josh Boyer <firstname.lastname@example.org>
Date: Fri May 25 16:14:15 2012 -0400
Upstream e1c972b681bf118fcedb9fe2ed7a73de983aa5ef makes it depend on
UIDGID_CONVERTED which is only set when all of the subsystems have been
converted to be user namespace safe. That defaults to Y whenever it happens,
so we'll set this after that point.
As of 3.8 there is the foundation of new user namespace support merged, and 3.9 kernel improve on it further. We want to support user namespacs in libvirt for the LXC driver, so require CONFIG_USER_NS to be re-enabled in F19 kernels.
We did recently enable CONFIG_NAMESPACES
Author: Josh Boyer <email@example.com>
Date: Wed Feb 6 11:44:09 2013 -0500
Enable CONFIG_NAMESPACES everywhere (rhbz 907576)
but even though CONFIG_NAMESPACES is documented as enabling all namespaces, it does not in fact enable CONFIG_USER_NS.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ls /proc/self/ns
'user' is not listed
'user' is listed
3.8 required a bunch of filesystems to still disabled before USER_NS could be turned on. 3.9 improves as you said, but it still depends on UIDGID_CONVERTED and that is such:
# True if all of the selected software conmponents are known
# to have uid_t and gid_t converted to kuid_t and kgid_t
# where appropriate and are otherwise safe to use with
# the user namespace.
depends on XFS_FS = n
So we would have to turn off XFS in order to enable USER_NS. We're not going to do that.
Looks like XFS is the only think blocking this though, so assuming we got a solution to XFS, would you be ok to enable it?
(In reply to comment #2)
> Looks like XFS is the only think blocking this though, so assuming we got a
> solution to XFS, would you be ok to enable it?
As far as I know, yes. Eric Biederman said:
"XFS is the only filesystem that remains. I was hoping I could get that
in this release so that user namespace support would be enabled with an
allyesconfig or an allmodconfig but it looks like the xfs changes need
another couple of days before it they are ready."
in his upstream 3.9 pull request. Whether "couple of days" means "I'll submit this after the merge window closes" or "I'll submit this for 3.10" remains to be seen.
3.9-rc1 is out and the XFS stuff is not included, so looks like we're heading for 3.10 territory now.
Unprivileged user namespaces are not ready. Here's couple of very recent examples why:
Enabling CONFIG_USER_NS on a kernel with upstream commit 5eaf563e53294d6696e651466697eb9d491f3946 (userns: Allow unprivileged users to create user namespaces) that removes the privilege checks when requesting CLONE_NEWUSER would currently put our users at big risk.
Petr Matousek / Red Hat Security Response Team
(In reply to comment #5)
> Unprivileged user namespaces are not ready. Here's couple of very recent
> examples why:
> * http://stealth.openwall.net/xSports/clown-newuser.c
> * https://lkml.org/lkml/2013/3/1/603
> Enabling CONFIG_USER_NS on a kernel with upstream commit
> 5eaf563e53294d6696e651466697eb9d491f3946 (userns: Allow unprivileged users
> to create user namespaces) that removes the privilege checks when requesting
> CLONE_NEWUSER would currently put our users at big risk.
Yeah. Hopefully all that gets cleared up for 3.10. I'm putting the FutureFeature keywork here to make it clear we aren't doing this soon.
FYI upstream has now converted XFS to work with user ns:
Author: Dwight Engen <firstname.lastname@example.org>
Date: Thu Aug 15 14:08:04 2013 -0400
enable building user namespace with xfs
Reviewed-by: Dave Chinner <email@example.com>
Reviewed-by: Gao feng <firstname.lastname@example.org>
Signed-off-by: Dwight Engen <email@example.com>
Signed-off-by: Ben Myers <firstname.lastname@example.org>
The Fedora 21 rawhide kernel looks like it includes this change, so cn we get USER_NS enabled in Fedora rawhide now.
If there are still security concerns, then I would be ok with having change 5eaf563e53294d6696e651466697eb9d491f3946 reverted in Fedora kernels initially. This would let privileged users make use of user namespaces, without increasing attack surface exposed to non-privileged users of the host.
Libvirt only needs to be able to use CLONE_NEWUSER when running as root, so this would be sufficient to let libvirt with with user namespaces in Fedora iniitally.
(In reply to Daniel Berrange from comment #7)
> If there are still security concerns, then I would be ok with having change
> 5eaf563e53294d6696e651466697eb9d491f3946 reverted in Fedora kernels
> initially. This would let privileged users make use of user namespaces,
> without increasing attack surface exposed to non-privileged users of the
> Libvirt only needs to be able to use CLONE_NEWUSER when running as root, so
> this would be sufficient to let libvirt with with user namespaces in Fedora
I'm fine with this approach.
My apologies for the delay here.
I've taken the suggestion Daniel made and pushed it to today's rawhide git tree. The first kernel to contain the support should be:
and will hopefully be in rawhide tomorrow.
I'm going to leave this bug as modified and I would really appreciate it if people could test the kernel and tell me if it's suitable for their needs.
Thanks Josh, I'll do some tests from libvirt's POV and report back.
(In reply to Daniel Berrange from comment #10)
> Thanks Josh, I'll do some tests from libvirt's POV and report back.
Did that happen?
Opps, yes. This is basically working from libvirt's POV. We did find one regression in the 3.12 kernel, but it isn't a show stopper so for now we'll just fine to wait for upstream fix to trickle down.
For reference the bug I was referring to above is this one https://lists.linuxfoundation.org/pipermail/containers/2013-November/033635.html
OK, close this out then.
It looks like unprivileged clone(CLONE_NEWUSER) is disabled, but unprivileged unshare(CLONE_NEWUSER) is enabled. This makes no sense.
This appears to be caused by:
Can we just drop this? This creates a weird incompatibility between Fedora and everything else.
(In reply to Andy Lutomirski from comment #15)
> It looks like unprivileged clone(CLONE_NEWUSER) is disabled, but
> unprivileged unshare(CLONE_NEWUSER) is enabled. This makes no sense.
Yeah, Petr noticed this last week and I forgot about it over the weekend.
> This appears to be caused by:
> ApplyPatch Revert-userns-Allow-unprivileged-users-to-create-use.patch
> Can we just drop this? This creates a weird incompatibility between Fedora
> and everything else.
Maybe. It's either drop it or disallow unshare(CLONE_NEWUSER).
Originally we went with the revert because userns had a number of exploitable CVEs when it came out. I believe there were more than a few even after we started carrying that patch. We fixed them all anyway, but the idea was to mitigate things until userns matured. It's not immediately obvious to me that it's matured, but I would allow that it's gotten somewhat better in the meantime.
FWIW, Petr found that Ubuntu has a somewhat more complete approach to disallow both here:
so it isn't just Fedora that is changing the behavior here.
Serge and I were discussing an LSM hook to control userns creation at KS/LSS this week.
In any case, I think his patch should be checking ns_capable relative to the would-be parent of the new namespace, not relative to the root userns. After all, none of the userns holes so far have allowed one to break out of the parent namespace in a way that couldn't be done just as easily by someone with CAP_SYS_ADMIN in the parent.
We talked about this a bit today. I think we're going to just drop the patch entirely and go with upstream here. Once more unto the breach and all that...
Done in Fedora git. It will be in the next respective builds done.
kernel-3.15.10-201.fc20 has been submitted as an update for Fedora 20.
kernel-3.15.10-201.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Is there any chance of this, unprivileged user namespaces, getting backported to 3.10 for RHEL7?
+1 for support in RHEL7
Feature requests for RHEL need to be done either via the Customer Portal or through a bug reported against the RHEL product. Comments in this bug will not be seen by the appropriate people. Thank you.