• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• [ Next ] In reply to: Ben Laurie

> > 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.

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.

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.

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.

> > The "trusted agent" I had in mind is an "open file" utility....
>
> Who is the user in this case? How can I alert someone who may be in bed
> (remembering we are talking about webservers here)?

In a hands-off server environment, you cannot. The best the user can do is say "that agent only gets access to a temporary file system that is blown away when it exits and is not shared", or "that agent can only see the following stuff, and then only in read-only form" or some such a priori policy determination.

shap

• [ Next ] In reply to: Ben Laurie