Jonathan S. Shapiro wrote:
>
> > > The sorts of leaks you are concerned about can occur only when an
> > > untrusted program holds (simulaneously or in sequence) a capability
> > > conveying access to sensitive data and also a capability conveying
> > > authority to communicate with an unauthorized party.
> >
> > This is where it gets interesting, I think. How does the authority tie
> > in with the party we communicate with?
>
> This question really has three parts: authentication, access, and
> scoping.
>
> Scoping first:
>
> In EROS, capabilities have meaning only within a single machine. In
> other capability systems, capabilities may be distributed. In the
> context of web servers the latter doesn't really arise, as the HTTP
> protocol does not include capability transfer facilities.
Well, don't forget I was actually talking about HTTPS, which includes certificates. Those could certainly be used for capability transfer. In fact, that is seen by many as their primary function (see SPKI, for example).
> Authentication:
>
> So now the question of authentication. This is not an OS problem;
> it's an application problem. While it *may* be advantageous for the
> application to leverage standard modules for things like passwords and
> challenge/response protocols, that's only the first step. Apache, for
> example, might select the authentication protocol contingent on the
> alleged client IP address; this is an example of why authentication
> mechanisms are app-specific.
Agreed.
> Authentication to the web server does not necessarily imply
> authentication as far as anything else on the machine is concerned;
> that may (or may not) want to be an entirely separate concern.
>
> Now that I (the server) know that you (the client) are authenticated
> to the server, the question of what authority that should give you is
> also highly application dependent.
Also agreed.
> Access:
>
> In EROS, and in most capability systems, access tends to mean that
> being authenticated gets you access to some bucket of capabilities and
> some "agent". In this example, the agent is a copy of the web server
> or a copy of some CGI execution environment.
>
> The question is "What capabilities belong in the bucket?" At the risk
> of engaging in a cop-out, the answer is "the smallest, weakest set
> sufficient to meet the environment's functional contract."
>
> What does this mean? I don't know. What application problem are you
> trying to solve?
>
> > OK, what I still am not getting is how I can decide what capabilities a
> > program has according to who is at the other end of the network
> > connection. This seems vital to me.
>
> An authentication agent provides a mapping from some authentication
> procedure to some bucket of capabilities. The bucket of capabilities,
> in a capability system, *is* the user's identity in all meaningful
> ways; there is no other meaning to the notion of user than that once
> you are past the authenticator.
>
> What's initially in the bucket? This is determined by the system
> administrator. Whether the user can augment that set (e.g. saving
> capabilities they may receive via authorized channels) across sessions
> is also administrator controllable.
Ah, OK, I think I'm beginning to get the picture.
An interesting twist, even in a standard HTTP server is that there are effectively two (or more) users. There's the "client user", i.e. the guy who is running the web browser, and there's the "content user", i.e. the guy providing the content/CGI/whatever. The content user varies according to URL, of course. So, translating this into capability-speak, presumably what I'm getting at is that the guy who is supplying content should be able to attach capabilities to the content, right? And also choose how those capabilities relate to the identity of the client user (or something)?
Cheers,
Ben.
-- Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org and Technical Director|Email: ben@algroup.co.uk | A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/ London, England. |"Apache: TDG" http://www.ora.com/catalog/apache