linux-kernel - Re: [capabilities] Allow normal inheritance for a configurable set of capabilities

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: <20150203154651.GC2923@mail.hallyn.com>
Date:	Tue, 3 Feb 2015 16:46:51 +0100
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Serge Hallyn <serge.hallyn@...ntu.com>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Christoph Lameter <cl@...ux.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Jonathan Corbet <corbet@....net>,
	Aaron Jones <aaronmdjones@...il.com>, Ted Ts'o <tytso@....edu>,
	LSM List <linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...uxfoundation.org>
Subject: Re: [capabilities] Allow normal inheritance for a configurable set
 of capabilities

Quoting Andy Lutomirski (luto@...capital.net):
> On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn <serge.hallyn@...ntu.com> wrote:
> > Quoting Casey Schaufler (casey@...aufler-ca.com):
> >> I'm game to participate in such an effort. The POSIX scheme
> >> is workable, but given that it's 20 years old and hasn't
> >> developed real traction it's hard to call it successful.
> >
> > Over the years we've several times discussed possible reasons for this
> > and how to help.  I personally think it's two things:  1. lack of
> > toolchain and fs support.  The fact that we cannot to this day enable
> > ping using capabilities by default because of cpio, tar and non-xattr
> > filesystems is disheartening.  2. It's hard for users and applications
> > to know what caps they need.  yes the API is a bear to use, but we can
> > hide that behind fancier libraries.  But using capabilities requires too
> > much in-depth knowledge of precisely what caps you might need for
> > whatever operations library may now do when you asked for something.
> 
> None of this could address the problem here, though: if I hold a
> capability and I want to pass that capability to an exec'd helper, I
> shouldn't need the fs's help to do this.

Yes you should.  It's not about needing the fs's help, it's about the
binary on the exec being imbued with some part of the privilege.  In TE
paralance it would be an entry point to the privilege.  I'm not saying "that's
how it should be", just "that's how posix caps work".

So again I think the pA seems like an elegant way to work around this.
I'm interested in other ideas, but I worry about the proc solution Christoph
proposed because it would be system- or namespace-wide, rather than
per-process.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/