Bug 917708

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:

config UIDGID_CONVERTED
        # 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.
        bool
        default y

        # Filesystems
        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:

  * http://stealth.openwall.net/xSports/clown-newuser.c

  * https://lkml.org/lkml/2013/3/1/603

  * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=db04dc679bcc780ad6907943afe24a30de974a1b

  * https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c61a2810a2161986353705b44d9503e6bb079f4f

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
> 
>   *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=db04dc679bcc780ad6907943afe24a30de974a1b
> 
>   *
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=c61a2810a2161986353705b44d9503e6bb079f4f
> 
> 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:

  commit d6970d4b726cea6d7a9bc4120814f95c09571fc3
  Author: Dwight Engen <dwight.engen>
  Date:   Thu Aug 15 14:08:04 2013 -0400

    enable building user namespace with xfs
    
    Reviewed-by: Dave Chinner <dchinner>
    Reviewed-by: Gao feng <gaofeng.com>
    Signed-off-by: Dwight Engen <dwight.engen>
    Signed-off-by: Ben Myers <bpm>
. 
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
> 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.

I'm fine with this approach.

Thanks,
Petr

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:

kernel-3.13.0-0.rc0.git3.2.fc21

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:

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.

(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:

http://kernel.ubuntu.com/git?p=serge/ubuntu-saucy.git;a=commitdiff;h=5c847404dcb2e

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.
https://admin.fedoraproject.org/updates/kernel-3.15.10-201.fc20

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.