[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!]
       Date: 	Sat, 17 Apr 1999 15:11:45 +0200
    From: Pavel Machek <>

    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

    - Ted

    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.023 / U:114.940 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site