Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> wrote:
>>[snip my so-simple-it's-probably-braindead UID<->Capability system]
>
> This is re-implementing the "setuid to xyz" facility in a capability (as
> assigned to a UID) system. I don't think it is as strong as a capability/inode
> reference. No user can accidentially (even indirectly) gain a privlege that
> is not explicitly assigned. This is NOT to say "privileges/capabilies" are
> not assigned to a UID. It is not done explicitly. The assignment only says
> "this uid is allowed to use the specified capabilities". The capabilities are
> not allways on. The combination of inode capabilities must be matched against
> the "allowed" capabilities. I realize this appears to contradict the inode
> reference - I think this is where the "forced" capabilities come into play.
Ok, so let me try to repeat what you just said, to clarify:
a) UID <-> Capabilities for ``allowed'' capabilities for a UID
b) SETUID on an inode to enable the capabilities
c) The inode carries a mask that further restricts the the capabilities
d) The executable can then drop capabilities from this final
mask. ie:
UID 0x00FE -> Inode 0x0079 -> Executable drops 0x0040 -> 0x0031
Correct?
> I think the "forced" capabilities permit totally unprivileged users to
> accomplish something that does require privilege - such as changing a password.
> It doesn't grant the ability to change just any password; only the password
> of the user using the passwd utility, even then the user must provide the
> old password. Changing any password requires additional capabilities/role
> definition (such as security administrator - there may be several capabilities
> used to define the role of security admin).
Now that type of fine grained control is kinda difficult for the
kernel (aestetically) to enforce... If capabilities need to be that
fine grained, then maybe (as I have heard discussed in this thread IIRC)
we should have a ``security service'' - a user-land daemon that gets
a RPC from the kernel on every capability influenced
open/close/read/write/mount/etc. to verify that the UID can perform
that action.
Much more extensible, small amount of kernel work, and no in-kernel
policy.
Now, I've got to ask the list - ``If you were to design a Trusted
Linux System, how would you go about it?''
Send concepts directly to me (jmcmullan@linuxcare.com) - let's keep that
level of traffic off the list. I'll collect all the replies I get, and
generate a digest of the results, with pointers to the original emails
[unless, of course, you want to be anonymous]
Submissions will be accepted until March 4, GMT 00:00 2000.
Digest will be placed on the WWW at http://zhrodague.net/~jmcc/
by March 6, GMT 00:00 (barring flood, fire, or famine)
I want to put all this into a FAQ format, so that we can point
people to what's already been discussed next time this flamewar
erupts on linux-kernel. ;^)
[actually, it's been more of a slowly-burning-incense-stick war, but hey..]
-- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 415.701.0792 fax jmcmullan@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution.- 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/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:21 EST