linux-kernel - Re: [PATCH RFC] Introduce new 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]

Message-ID: <CALCETrV_McoPAFvXbZAOfWPpj6rMbYFZvrusVi9_yXsBXHkN0A@mail.gmail.com>
Date:	Wed, 27 Jan 2016 16:36:02 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Jann Horn <jann@...jh.net>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Andrew Morgan <morgan@...nel.org>,
	LXC development mailing-list 
	<lxc-devel@...ts.linuxcontainers.org>,
	Richard Weinberger <richard@....at>,
	LSM <linux-security-module@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH RFC] Introduce new security.nscapability xattr

On Wed, Jan 27, 2016 at 9:22 AM, Jann Horn <jann@...jh.net> wrote:
> 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.

But another option would be to include a list of uids and gids such
that the cap bits on the file are trusted by any namespace that maps
only uids and gids in the list.  After all, the existence of a
namespace with root user foo that also maps bar and baz along with a
file with caps set means that, if baz can get to the file and
permissions are set appropriately, then baz now owns bar (via any
number of fs-related capabilities).  So maybe bar and baz should have
to be listed as well.

But maybe this doesn't matter.

In any event, at the end of the day, the right answer to all of this
is to stop using setuid and stop using cap bits too and start using
privileged daemons or other things that don't use the eternally
fragile grant-privilege-on-execve mechanisms.

--Andy