Messages in this thread | | | From | (David Wagner) | Subject | Re: [PATCH] capabilities not inherited | Date | Thu, 9 Jun 2005 02:59:19 +0000 (UTC) |
| |
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/
| |