Messages in this thread | | | Date | Tue, 3 Feb 2015 18:28:37 +0100 | From | "Serge E. Hallyn" <> | Subject | Re: [capabilities] Allow normal inheritance for a configurable set of capabilities |
| |
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 <serge.hallyn@ubuntu.com> 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
| |