[Devel] Re: [PATCH 1/1] RFC: taking a crack at targeted capabilities

[Serge E. Hallyn]

Quoting Eric W. Biederman (ebiederm at xmission.com):
> "Serge E. Hallyn" <serue at us.ibm.com> writes:
> 
> > So i was thinking about how to safely but incrementally introduce
> > targeted capabilities - which we decided was a prereq to making VFS
> > handle user namespaces - and the following seemed doable.  My main
> > motivations were (in order):
> >
> >         1. don't make any unconverted capable() checks unsafe
> >         2. minimize performance impact on non-container case
> >         3. minimize performance impact on containers
> 
> My motivation is a bit different.  I would like to get to the
> unprivileged creation of new namespaces.  It looks like this gets us
> 90% of the way there, with only potential uid confusion issues left.
> 
> I still need to handle getting all caps after creation but otherwise I
> think I have a good starter patch that achieves all of your goals.
> 
> Of course kill_permission needs the checks you have suggested as well.
>
> Eric
> 
> 
> >From db104af741b5f0a2f128688905498cae68fbbde2 Mon Sep 17 00:00:00 2001
> From: Eric W. Biederman <ebiederm at xmission.com>
> Date: Wed, 6 Jan 2010 08:26:21 -0800
> Subject: [PATCH] security:  Make capabilities relative to the user namespace.
> 
> - Introduce ns_capable to test for a capability in a non-default
>   user namespace.
> - Teach cap_capable to handle capabilities in a non-default
>   user namespace.

So yeah, I didn't address the whole has_capability junk.  Feh.

So do you intend to tag all namespaces with the userns which
created it?  So sys_hostname() can check utsname->uts_ns->creator,
and net ioctl SIOCSIFNAME checks struct net->creator?

-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers