linux-kernel - Re: [PATCH 1/1] simplified security.nscapability xattr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 May 2016 09:25:26 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	"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

Quoting Eric W. Biederman (ebiederm@...ssion.com):
> "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.

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