Jim Dennis wrote:
> This is all very interesting -- however I have a
> question...
>
> Is there a way that we could add a slightly more generalized
> interface for processes to be associated with a list of
> "capabilities" (* a la KeyKOS, EROS, et al) -- and then use
> that interface to provide PAG's?
I have been thinking about a capability oriented OS for quite some time
now. Even though there is virtually no code written yet, I have come up
with a few ideas which could be discussed if we were to start a project
to provide Linux with such a beast:)
> * (for more info on these look at www.starshine.org/jim/os/)
However, I never read any of this:) Is this the 100th Monkey syndrome?:)
> The need for authentication mechanisms that are independent
> of process uid (euid, fsuid, gid, etc) is more widespread
> than just Coda -- and it would be a shame for each application
> (protocol) that needed it to implement different kernel
> level changes to provide essentially identical features
> (capabilities).
Actually, current uid dependant authentication mechanisms (and similar)
could be replaced in whole by a general 'capability access control
mechanism' - for example, to be able (capable) to successfully open a
file, process must be allowed to use the 'open file' capability (=
open()) on the given object (file). This can be controlled by the system
selectively giving each capability as processes request them. For
example, for the file to be opened, the process must request the 'open
file' capability from the system, and the system can then evaluate if
the process meets the cryteria to be allowed to use the capability (for
example process_uid == 0, process_gid == 0, file_owner_uid == 0,
12:00:00 < time < 18:00:00, file_size <= 1000000, etc..)
This can preserve all of the current functionality plus extend it by a
whole lot, allowing arbitrarily coarse control over virtually all system
resources! And this can be made in a layered way where a parent (that
executes in some layer) can control the capabilities that its childred
(that execute in one layer lower) may use.
> Unfortunately, in this regard, I'm just an armchair coach.
> However, I'd really like to know if there's any way we could
> provide a set of "capabilities" extensions to Linux and
> thereby reduce our dependence on the all-powerful and
> absolutely corruptable 'root'.
As far as I have thought about it, I have come to the conclusion that
Linux lacks a few of the features I found necessary in order to
efficiently implement capabilities. Because in a capability oriented
system that I had in mind (see above, about layers; every layer in the
system can provide its set of capabilities, which may (or may not)
include the set of capabilities that the layer recieved from the layers
above), the line between the operating system and the application is
virtually nonexisting, so I wanted to implement as much of the system as
possible in the user space (if not, there could be only two layers,
which I found not to be satisfactory: kernel and applications), which
pulls along a whole batch of problems that would require substantial
changes to the kernel.
Since this is a vast subject I wouldn't want to write a novel here -
after all this is still the Linux kernel mailing list (even though I'd
just LOVE to see this in Linux:) If anyone is intrested in implementing
anything like this, please DO contact me privately.
> (I suspect that it we'd have to build a hybrid between
> Unix/Linux permissions (identity based) and the capabilities
> model -- perhaps by having a "flag" in the uarea that effectively
> tells the kernel and vfs code to check the process' "captable."
> This would also imply that we'd have some changes that would
> allow us to create and bind capabilities to files and processes
> -- although we could limit it to "just" files if we require
> /proc support to use this subsystem).
>
> Ultimately I suspect that a capabilities model would be
> far easier to implement than ACL's or the proposed "privs"
> (Orange book) features.
As far as I understand ACLs and the Privs project, the capability
oriented system would provide the same (and more) functionality that
these two projects are set to provide, only that with a capability
oriented system there would be only ONE interface.
> If the list objects to a thread on this topic, I'll be happy
> to take it offline and form a discussion group on it. Detractors
> (with substantive objections!) are welcome.
And I will gladly provide as much web and ftp space as needed if a
project should be started.
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si PGP public key: http://luna.s-gimsen.lj.edus.si/~andrejp/key.asc
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu