Re: [RFC] Capabilities still can't be inherited by normal programs

[Andy Lutomirski]

On Mon, Dec 10, 2012 at 6:59 AM, Serge Hallyn
<serge.hallyn@xxxxxxxxxxxxx> wrote:
> Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx):
>> It's especially bad because granting CAP_DAC_READ_SEARCH to user "foo"
>> doesn't mean anything.  Is he authorized to back things up to
>> encrypted storage?
>
> We're talking about privileges at the kernel level here, and there is
> no way this could be expressed at that level.
>
> Higher level tools could/should certainly be exposing things at this
> level.

Agreed, although selinux tries to allow this kind of detail in the
kernel.  I don't think capabilities should move in that direction.

>
> BUT
>
> You *are* doing a good job of making me feel that we should have
> per-user fI xattrs or acls.  Sudo is popular because people like to say
> "user joe can run foo with privilege".  Most people will never want to
> be bothered to say "user joe can run foo with CAP_XYZ" (versus "as
> root"), but I do think we could get programs/packages to do that.

Hmm.  I wish I was doing as good a job convincing myself that I know a
good solution.

I don't actually consider the fact that pI has insufficient
granularity to be a problem in need of fixing.  I think userspace can
take care of detailed authorization questions on its own.  I think the
problem is that pI is failing to allow users who aren't root (or at
least aren't uid=0) to have elevated, but not completely elevated,
privilege.  (If you don't like "users" in that sentence, feel free to
replace it with "trusted programs that use execve as part of their
operation".)

Part of my struggle in proposing a solution is that there are two
things I'd rather not add:

1. More modes.  securebits, etc are hard to understand and can break
assumptions that are currently true.

2. execve granting new privilege, even in the pI -> pP sense.  There
have been countless bugs relating to this in the past.  This is why I
proposed no_new_privs.

A new mode that is only allowed when no_new_privs is set is
considerably less dangerous, but still not wonderful.


I could write a patch to add a new securebit SECURE_CAP_INHERITANCE
that changes execve to act as though fI always contained all bits and
to change capset to prevent pI from ever exceeding pP & pB.  To make
it usable without CAP_SETPCAP, maybe setting it to true should be
legal without privilege if no_new_privs.

(Actually, maybe all of the securebits should be freely tweakable if
no_new_privs.)


Some use cases:

1. Write a pam module that sets SECURE_CAP_INHERITANCE and assigns
inheritable caps.  Obviously it would grant users full use of those
caps.  The question is: what else would break?  I.e. could users abuse
it to exploit other setuid or fP!=0 binaries?

2. Write little fP != 0 helpers that check authorization, set
no_new_privs and SECURE_CAP_INHERITANCE, and invoke something else.

3. (Pipe dream?)  Eventually convince everyone to run in
SECURE_CAP_INHERITANCE mode.


I'll admit I'm not really thrilled by this suggestion.

I'd like to do a survey and find out if anyone uses fI.  If the answer
is "no", fI support could be dropped in some kind of controlled
manner, perhaps using the vfs cap version number.  The setcap tool IMO
wants some reworking anyway.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/