From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [PATCH 1/1] simplified security.nscapability xattr Date: Tue, 3 May 2016 09:25:26 -0500 Message-ID: <20160503142526.GA6309@mail.hallyn.com> References: <1461345993-17526-1-git-send-email-serge.hallyn@ubuntu.com> <1461345993-17526-2-git-send-email-serge.hallyn@ubuntu.com> <20160426222627.GA19307@mail.hallyn.com> <20160502035452.GA31837@mail.hallyn.com> <87h9egp2oq.fsf@x220.int.ebiederm.org> <20160503051921.GA31551@mail.hallyn.com> <87bn4nhejj.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <87bn4nhejj.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Eric W. Biederman" Cc: "Serge E. Hallyn" , "Andrew G. Morgan" , Kees Cook , Jann Horn , Michael Kerrisk-manpages , "Serge E. Hallyn" , Linux API , Andy Lutomirski , Linux Containers , LKML List-Id: linux-api@vger.kernel.org Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org): > "Serge E. Hallyn" writes: > > > Quoting Andrew G. Morgan (morgan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. That's all fine if the kernel does it for us magically. Which is what we're talking about below. Above I was talking about userspace putting it into the xattr. > >> 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 All right. Excellent. I simply didn't think something like that would be acceptable. I tend to think of xattrs as just out of band file contents, but generally under user control. I guess that's not right. > 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. If we can do all the magic in the kernel behind the scenes, then I absolutely do not mind adding a new security.capability version with 4 more bytes. Userspace can just write the old xattr format with the new version number, kernel fills in the userns owner kuid. It's what I originally wanted to do, but didn't think was acceptable. Sounds great! -serge