> In message <Pine.GSO.4.10.9904171834190.21850-100000@weyl.math.psu.edu>, Alexan
> der Viro writes:
> +-----
> | On Sat, 17 Apr 1999, Theodore Y. Ts'o wrote:
> | > 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.
> +--->8
>
> Straw man.
>
> Capabilities defined that loosely aren't particularly useful. A better
> real-world example of a capability useful for mail programs would be: the
> ability to create and remove files owned by the process's uid in certain
> directories.
>
> This assumes some way to flag such directories, either by borrowing an unused
> standard permissions bit --- does setuid on a directory currently mean
> something? --- or by creating new permission bits. Ideally, it would be tied
> to an ACL system where a directory could have ACLs for capabilities as well
> as for users/groups. One could then create "capabilities" (the term "roles"
> probably fits better in this context) which exist solely to be assigned to
> ACLs and attached to specific programs; and in one stroke you've produced a
> fine-grained fix for a wide range of security problems currently solved by
> the use of setuid.
You don't need *anything* special for that. You don't need
capabilities - file descriptor of the directory will work just fine. Let
the daemon pass it to applications via SCM_RIGHTS (after proper
authentication, indeed) and call fchdir() in the application. Make the
directory inaccessible to anybody except the daemon (no exec for group
and world on parent) and there you go. You'll need to protect the thing
from reaching it via /proc/* - not a big deal.
-
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/