Message-ID: <54D0F94D.3050704@schaufler-ca.com>
Date:	Tue, 03 Feb 2015 08:37:33 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
CC:	Andy Lutomirski <luto@...capital.net>,
	Serge Hallyn <serge.hallyn@...ntu.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>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [capabilities] Allow normal inheritance for a configurable set
 of capabilities

On 2/3/2015 7:51 AM, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (casey@...aufler-ca.com):
>> On 2/2/2015 12:37 PM, Andy Lutomirski wrote:
>>> 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.
>> One of the holes in the 1003.1e spec is what to do with a program file
>> that does not have a capability set attached to it. The two options are
>> drop all capabilities and leave the capabilities alone. The latter gives
>> you what you're asking for. The former is arguably safer.
> Hm, so if we were to change that, what should we do in the case of (a)
> an fs which doesn't support xattrs,

You have two choices, really. The first is to treat the files on that
filesystem as having no xattrs, thus they have the inheritable behavior.
The alternative is to default to some value for the filesystem (Smack
does this) which may or may not be provided in the mount options.

>  (2) expanding a tarball/cpio which
> didn't have xattrs (should tar/cpio fill them in with empty sets?),
> and

Files get no capability sets, hence the inheriting behavior.

> (3) do we add a default empty set in the case of an fs mounted with
> NOSUID?

No, I think that is the opposite of what NOSUID is trying to do.
For the capability behavior to match the setuid bit behavior all
files will be inheriting, as if they had no capability set. It would
be safer to pretend there is an empty set, but that's not what
NOSUID does.

> It's an interesting notion.

It's what we did in Trusted Irix. It made life much easier.


--
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/

Powered by blists - more mailing lists