Jonathan S. Shapiro wrote:
> Finally, if somebody will tell me the newsgroup this started in, I'll
> post this to the newsgroup as well.
The original discussion about process authentication groups started on the Linux-kernel mailing list (linux-kernel@vger.rutgers.edu; the list is handled by a majordomo listserver; requests should go to majordomo@vger.rutgers.edu) and was continued by Jim Dennis and myself privately.
This was my post.
> > >>> .. current uid dependant authentication mechanisms (and similar)
> > >>> could be replaced in whole by a general 'capability access control
> > >>> mechanism'...
>
> This could mean two things:
>
> 1. the UID approach could be replaced by a capability approach,
> yielding a more secure system
>
> 2. the UID approach can be implemented on a capability substrate
>
> Both statements are correct. The second is useful for reasons of
> backward compatibility. KeyKOS, for example, has implemented a fairly
> complete UNIX binary compatibility system on top of a pure capability
> substrate.
Your observation is correct: our intent was actually to enhance Linux' (a UNIX-like OS) security by implementing concepts alternative to ACLs.
[snip]
> Obtaining capabilities:
>
> Capabilities can be obtained in two ways:
>
> 1. A process P1 can transmit a capability C that it holds to a process
> P2, assuming that P1 holds a capability to P2.
>
> 2. [deprecated] A process can make a request of some system agent to
> grant it certain capabilities on the basis of the program being
> run, a challenge-response protocol, or some such.
>
> The correct way to think about this is that the process had an
> intrinsic capability to some other process that holds desired
> capabilities and acts as an authentication agent.
>
> Such an authentication agent is necessary only when the system as a
> whole is not persistent -- the problem is how to reacquire
> capabilities when the system restarts. Authentication processes of
> this kind present some serious security design issues and render
> security analysis quite difficult.
>
> > >>> 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...
>
> It should now be clear that this statement is confused, on several
> grounds:
>
> 1. There can be no such thing as an 'open file capability' -- it
> fails the definition.
>
> 2. A process does not "request" a capability from the system.
> There are two problems in this notion:
>
> 1. In a capability system, a process has no intrinsic
> authority to request anything from anyone. It can only
> invoke capabilities. Unless the process has some
> capability to some agent holding useful authorities, it
> has no way to ask for more capabilities.
>
> 2. It begs the question of how the system might decide if
> the process is authorized to request that capability.
The 'request' can be thought of as one of the ways you mentioned about obtaining capabilities (A process P1 can transmit a capability C that it holds to a process P2, assuming that P1 holds a capability to P2 -> since P2 is started by P1, I assumed that P2 can 'request' (P2 is given the capability to ask for) the capabilities that it needs from P1; P1 can be thought of as 'system' and will evaluate whether capabilities should be transmitted to P2 or not).
I hope this clears things up a bit.
I thought of this 'request' when I was thinking about non-cpu-specific process startup methods and non-platform-specific system calls and it came as an obvious solution which obeys the can-do-nothing-without-authorization rule, is fast and is also relatively easy to implement (it actually simplifies a number of things and cleans the system interface up a bit, even though it requires slightly more work by the compiler/linker (or the programmer)).
[snip]
> The best way to keep hold of the capabilities that a process needs is
> to grant them from the beginning and ensure that they are never lost.
This was the original idea. The 'request' above is the means a process can obtain the needed capabilities. But since in the low level we always come to the terms of functions, I translated 'capabilities' to 'functions that perform specific actions on objects'.
Do you think that this translation is a good thing? I see difficulties in managing unnamed objects but at the time I felt that it's worth a thought.
[snip]
Mhm. So every capability can in every point in time have only one
holder?
> Note also that once created, the parent/child relationship is NOT the
> hierarchical relationship assumed by UNIX. The relationships are
> defined entirely by who holds what capabilities, and are therefore a
> potentially arbitrary graph.
>
> > > the parent ... may at any time for any reason terminate access to
> > > the capability ...
>
> In a capability system it cannot. The child either holds a capability
> or it doesn't. There is nothing in the capability that records where
> the capability came from. Once transferred, the sender has no control
> over how the receiver uses the capability.
> Observation: while you could build a modified capability system that
> used hierarchically constrained access rights, you would create to
> problems in doing so:
>
> 1. Undesired communication channels inherent in the access control
> hierarchy itself.
> 2. Variable-length capabilities.
>
> >From an implementation perspective, capabilities *really* want to be
> fixed size. Imagine programming a system with variable length
> pointers...
Hm. Can you give an example of the two mentioned problems?
> > The problem with doing it at a resolution finer than
Do you have an URL on this?
> > the system call level is that the performance starts to
> > suffer unacceptably.
>
> It depends entirely on the speed of the invocation mechanism. What
> you are really asking is: "How small can the reasonable granularity of
> a protected invocation be?" The faster the boundary-crossing logic
> is, the finer the operation that a protected invocation can protect
> while retaining acceptable performance. Liedtke (L3, L4) has a nice
> slide of this. He says:
>
> Suppose you are willing to devote 2% (or X%) of your system
> resources to protection boundary crossings. Here is a graph
> showing the number of crossings you can do as a function of
> crossing costs.
>
> The graph shows lines for several choices of X, several crossing
> speeds, and several numbers of crossings.
[snip]
> I really like some of the ideas you are considering. If they are
> combined with a true capability substrate I think they can be made
> secure.
>
> A personal plea:
>
> I have spent the past 7 years building a secure capability system.
> Your function-transfer security approach is completely different.
> For this reason it should not be called 'capabilities'. any
> OS-oriented dictionary will make it obvious that it isn't
> capabilities. Surely it's better all around to chooose a new term
> for a different idea?
>
> I ask that you not jeopardize my work and the work of all of the other
> people in the capabilities field by misusing the name.
No problem. The work that I have done has not been related to any of the systems that you mentioned here (as a matter of fact, this discussion is the first time that I have heard of any such systems). I picked the term 'capability' because I felt it described quite well the basic idea of the model that I'm trying to develope. I was not aware of existance of any such systems at the time when I picked the name. However, I feel that the idea that I was (probably in a very clumsy way) proposing is quite similar to a hyerarchycal capability model that you were talking about.
> Enough for now. I hope that some of this is useful, and I'll be happy
> to answer followups.
Your mail has been very illuminating and I hope to read more from you in the future.
Andrej
-- Andrej Presern, andrejp@luz.fe.uni-lj.si PGP public key: http://luna.s-gimsen.lj.edus.si/~andrejp/key.asc