[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!]
In message <>, 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.

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

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]
system administrator [WAY too many hats]
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
Please read the FAQ at

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