[lkml]   [1999]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: inheritable set [was Re: caps in elf headers: use the sticky bit!]

On Sat, 17 Apr 1999, Theodore Y. Ts'o wrote:

> 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

... i.e. would be able to modify files that don't belong to its UID. E.g.
/etc/passwd. Q.E.D.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.069 / U:1.784 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site