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.
One could get even finer-grained control, e.g. "can create files which are
named `X.lock' in a specified directory, where `X' is an existing file owned
by the uid of the process with the capability", but this is probably not a
good idea because it requires encoding that kind of restriction into the
kernel. Then again, a mechanism for loading byte-code capability definitions
--- itself controlled by a "permanent" capability --- could prove useful for
this level of control.
--
brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net
system administrator [WAY too many hats] allbery@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
We are Linux. Resistance is an indication that you missed the point.
-
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/