Messages in this thread |  | | | Subject | Re: inheritable set [was Re: caps in elf headers: use the sticky bit!] | | Date | Sat, 17 Apr 1999 20:14:33 -0400 | | From | "Brandon S. Allbery KF8NH" <> |
| |
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: | > 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 | > 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.
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/
|  |