On Fri, Jan 29, 2016 at 01:31:51AM -0600, Serge E. Hallyn wrote:

On Wed, Jan 27, 2016 at 04:36:02PM -0800, Andy Lutomirski wrote:

quoted

On Wed, Jan 27, 2016 at 9:22 AM, Jann Horn [off-list ref] wrote:

quoted

I think it sounds good from a security perspective.

I'm a bit late to the game, but I have a question: why should this be
keyed to the *root* uid of the namespace in particular?  Certainly if
user foo trusts the cap bits on some file, then user foo might trust
those caps to be exerted over any namespace that user foo owns, since
user foo owns the namespace.

...  Tying it to a kuid which represents the userns->owner of any
namespace in which the capability will be honored might be fine
with me.  Is that what you mean?  So if uid 1000 creates a userns
mapping uids 100000-200000, and 100000 in that container puts X=pe
on /bin/foo, uid 101000 in that container runs /bin/foo with privilege
X.  Uid 101000 in someone else's container does not.

Although, if I create two containers and provide them different
uidmaps, it may well be because I want them segragated and want
to minimize the changes of one container breaking out into the
other.  This risks breaking that.

Thinking differently now...  I really want it to "just work" to tar
and untar these.  So I'm thinking of simply using the file owner
as the uid.  So to write a security.ns_capability xattr, you must
be uid 0 in the inode's namespace, the file must be owned by uid 0,
and the capabilities in the xattr will be honored for any namespace
where in that uid_t 0 is root.

Does that sound overly restrictive?  I expect file capabilities to
be used on files owned by root but not setuid-root, so I think it
is ok.

-serge