Re: [PATCH] capabilities not inherited

[daw@taverner.cs.berkeley.edu (David Wagner)]

Alexander Nyberg  wrote:
>btw since the last discussion was about not changing the existing
>interface and thus exposing security flaws, what about introducing
>another prctrl that says maybe PRCTRL_ACROSS_EXECVE?

Not sure if I understand the semantics you are proposing.

I remember that the sendmail attack involved the attacker clearing
its SETUID capability bit, then execing sendmail.  Sendmail, the victim,
got executed with fewer capabilities than it expected, and this caused it
to fail (in particular, sendmail's attempt to drop privileges silently
failed) -- leading to a security hole.  Will your proposal prevent such
attacks?  I'm worried.

>Any new user-space applications must understand the implications of
>using it so it's safe in that aspect. Yes?

Not clear.  Suppose Alice exec()s Bob.  

Does your scheme protect Alice against a malicious Bob?  Yes, because
Alice has to know about PRCTRL_ACROSS_EXECVE to use it.

Does your scheme protect Bob against a malicious Alice?  Not clear.
If Alice is the only who has to set PRCTRL_ACROSS_EXECVE, then Bob might
not know about this flag and thus might be surprised by the implicatiohns
of this flag.  Consequently, I can imagine this flag might allow Alice
to attack Bob by exec()ing Bob with a different set of capabilities than
Bob was expecting.  Does this sound right?

But maybe I'm not thinking clearly enough about this.  This is tricky
stuff.
-
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/