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

[Andrew G. Morgan]

On Fri, Dec 7, 2012 at 10:39 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On Fri, Dec 7, 2012 at 9:07 AM, Andrew G. Morgan <morgan@xxxxxxxxxx> wrote:
>> I'm still missing something with the problem definition.
>>
>> So far if I follow the discussion we have determined that inheritance
>> as implemented is OK except for the fact that giving user an
>> inheritable pI bit which gives them default permission to use all
>> binaries endowed with the corresponding file fI bit.
>
> This is IMO part of the problem but not the entire problem.
>
>>
>> Is this the problem a different inheritance model is supposed to
>> address? Serge suggested that the binary could authenticate the
>> user... This seems like its putting the protection in the best
>> place... Each app can control its sub functions with the richest
>> semantics.
>>
>> That being said...
>>
>> To me this looks like it's an access control problem... Namely use
>> acls to limit which users (groups) can execute each privileged binary.
>> Serge's option 2 seems like a similar approach.
>>
>
> The issue is (as I see it) with non-privileged binaries.  If a given
> program (correctly) has a permitted capability and is not root, then
> the only way that it can pass that capability on to children (e.g.
> helper programs) is to set it into pI.  This only works if the child
> has the same bit set in fI.

Yes.

> This is doable but annoying -- every program that a privileged program
> runs needs to be authorized by the administrator.

Yes.

> It breaks down because, currently, users with nonzero pI have no
> direct ability to wield the capabilities.  That means that every
> single binary with fI bits set needs to be as careful as a setuid-root
> binary to avoid leaking privilege to the caller.  (Obviously, binaries
> with fP set need to be careful.  IMO binaries with only fI set should
> not need to exercise any particular care to defend themselves from
> their callers.)

True. But what about protecting the system from privileges they didn't
expect to have?

> I'm obviously missing some fundamental (and probably historical) issue
> here, so let me ask the following straw-man question.  Suppose
> capabilities worked like this on exec:
>
> pP' = pI | (fP & pB)  (i.e. the current way, except that fI always has
> all bits set for every binary on the system)
> pI' = pI (unless !SECURE_NOROOT and uid == 0 or euid == 0, in which
> case pI' = pP')
>
> with the added restriction that pI is always a subset of pP (i.e.
> dropping a bit from pP (on exec or otherwise) drops that bit from pI).
>
> What would be wrong with this model?  (Let's pretend for now that
> capabilities had always worked this way, so there's no change of
> behavior to worry about.)
>
>  - The sendmail capability bug wouldn't happen: pI has no effect on
> setuid-root binaries.

Are you saying that setuid-root is required for a program like
sendmail to work? Forever?

>  - There would be no difference between a user being trusted with a
> capability and being inh-trusted with that capability, since the
> latter concept wouldn't really exist.

See below. It's key to see that it is not people, but programs that
require privilege.

>  - Totally unprivileged users couldn't engage in any funny business.
> Their pI masks would be zero, and they would have no way of changing
> that.
>
>  - Partially privileged users would work just fine.  They could wield
> their capabilities (subject to some possible fiddling with pE) from
> bash or from anything else.  They could also freely drop those
> capabilities.
>
>  - Privileged programs would require less thought: to grant a program,
> you set its privilege in fP.  There is no fI, so there's nothing
> special to think about.
>
>
>
> NB:  This is not a real proposal because there *are* capability-aware
> programs out there.  I want to understand why the current system is so
> different.

I think you have correctly determined a key difference (a fundamental
feature!) of the model.

For an explanation, please search for "key insight" in the OLS paper:

  http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf

Also, see p310+ of the first document linked to on the page Casey pointed to:

  http://wt.tuxomania.net/publications/posix.1e/download.html

which has quite an elaborate explanation of how this model was
designed, and what the authors were trying to achieve.

Cheers

Andrew

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