[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bn4nhejj.fsf@x220.int.ebiederm.org>
Date: Tue, 03 May 2016 00:54:40 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: "Andrew G. Morgan" <morgan@...nel.org>,
Kees Cook <keescook@...omium.org>, Jann Horn <jann@...jh.net>,
Michael Kerrisk-manpages <mtk.manpages@...il.com>,
"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
Linux API <linux-api@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
Linux Containers <containers@...ts.linux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] simplified security.nscapability xattr
"Serge E. Hallyn" <serge@...lyn.com> writes:
> Quoting Andrew G. Morgan (morgan@...nel.org):
>>
>> I guess I'm confused how we have strayed so far that this isn't an obvious
>> requirement. Uid=0 as being the root of privilege was the basic problem
>> that capabilities were designed to change.
>
> The task executing the file can be any uid mapped into the namespace. The
> file only has to be owned by the root of the user_ns. Which I agree is
> unfortunate. We can work around it by putting the root uid into the xattr
> itself (which still isn't orthogonal but allows the file to at least by
> owned by non-root), but the problem then is that a task needs to know its
> global root k_uid just to write the xattr.
The root kuid is just make_kuids(user_ns, 0) so it is easy to find.
It might be a hair better to use the userns->owner instead of the root
uid. That would allow user namespaces without a mapped root to still
use file capabilities.
>> Uid is an acl concept. Capabilities are supposed to be independent of that.
>>
>> If we want to support NS file capabilities I would look at replacing the
>> xattr syscall with a dedicated file capabilities modification syscall. Then
>
> That was one ofthe possibilities I'd mentioned in my earlier proposal,
> fwiw. The problem is if we want tar to still work unmodified then
> simple xattr operations still have to work.
>
> Maybe there's workable semantics there though. Worth thinking about.
If the problem is compatibilty please look at
posix_acl_fix_xattr_from_user. With something similar for the
security.capability attribute we can perform whatever transformation
makes sense. I admit adding 4 bytes is a bit of a pain in that context
but not a big one.
Eric
Powered by blists - more mailing lists