Messages in this thread | | | Date | Sat, 17 Apr 1999 18:01:16 -0400 (EDT) | From | "Theodore Y. Ts'o" <> | Subject | Re: inheritable set [was Re: caps in elf headers: use the sticky bit!] |
| |
Date: Sat, 17 Apr 1999 15:11:45 +0200 From: Pavel Machek <pavel@bug.ucw.cz>
Which only means that "more" should have inheritable set equal to zero. I _still_ do not see why setting inheritable set should be privileged operation.
If it's not a privileged operation, then the attacker can change the inheritable set of "more" first....
Ok, given example with "more"... I do not think inheritable set of "more" set to NULL would help: even if it was that way, shell executed from more would have uid == 0 and no privileges. But what user owns /etc/passwd? uid == 0. And I've got a shell with... uid == 0. So I do not need any privilege (it is owned by same uid!) to edit /etc/passwd and you are screwed; anyway. I could this be solved in "pure capabilities" system, but I do not see how you want to fit protection against "more" attack and still be unix.
You can do full POSIX capabilities and still be Unix; and the way you solve this problem using model outlined by the POSIX capabilities draft is that /usr/ucb/Mail would no longer be setuid root, so "more" would not be running with uid 0, and neither would the shell executing from more. /usr/ucb/Mail would instead have a capability which allowed it to override filesystem discretionary access controls, or whatever other capabilities/privileges it needed. But it would not need to be setuid root.
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |