lkml.org 
[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
From
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/

\
 
 \ /
  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