Re: [PATCH] capabilities not inherited

[Alexander Nyberg <alexn@telia.com>]

tor 2005-06-09 klockan 02:59 +0000 skrev 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.

I'll look this up but it sounds very weird and I don't see how this
would happen with this change.

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

Yeah but for capabilities to be useful it needs to be recursive too, ie.
Alice runs Bob that in turn runs Joe. Joe should now have the
capabilities that Alice had if Alice had set PCRTL_ACROSS_EXECVE and Bob
did not drop the PRCTL flag nor zeroed the inheritable mask.

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

That would require Alice to already have the capabilities. No extra
capabilities are gained by exec'ing, it's only about inheriting the
existing ones.