Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756105AbbBCR2l (ORCPT ); Tue, 3 Feb 2015 12:28:41 -0500 Received: from h2.hallyn.com ([78.46.35.8]:43625 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686AbbBCR2j (ORCPT ); Tue, 3 Feb 2015 12:28:39 -0500 Date: Tue, 3 Feb 2015 18:28:37 +0100 From: "Serge E. Hallyn" To: Casey Schaufler Cc: "Serge E. Hallyn" , Andy Lutomirski , Serge Hallyn , Christoph Lameter , Serge Hallyn , Jonathan Corbet , Aaron Jones , "Ted Ts'o" , LSM List , "linux-kernel@vger.kernel.org" , Andrew Morton Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities Message-ID: <20150203172837.GC4748@mail.hallyn.com> References: <54CFB9B8.8020701@schaufler-ca.com> <20150202180806.GE24351@ubuntumail> <54CFE3E8.2030402@schaufler-ca.com> <20150203155122.GD2923@mail.hallyn.com> <54D0F94D.3050704@schaufler-ca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D0F94D.3050704@schaufler-ca.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3256 Lines: 63 Quoting Casey Schaufler (casey@schaufler-ca.com): > On 2/3/2015 7:51 AM, Serge E. Hallyn wrote: > > Quoting Casey Schaufler (casey@schaufler-ca.com): > >> On 2/2/2015 12:37 PM, Andy Lutomirski wrote: > >>> On Mon, Feb 2, 2015 at 10:08 AM, Serge Hallyn wrote: > >>>> Quoting Casey Schaufler (casey@schaufler-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. Is there any chance you'd have time to write a patch to implement this? (I wasn't going to ask bc I assumed not, but heck maybe you're bored on a desert island or snowed in and just looking for an excuse to hack :) -serge -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/