[cap-talk] the "flaw" of separating designation from authority

[Fred Spiessens]

On 27 Oct 2006, at 22:53, Karp, Alan H wrote:

> Fred Spiessens wrote:
>>
>> So, MyFileSystem is provided as a file-library in the
>> language, and the programmer is forced to use it, directly or
>> indirectly, when writing client data to a file and logging it
>> to his own file in one atomic action?
>>
> Not quite.  MyFileSystem is provided by a service that acts on  
> behalf of
> many users.  The service updates the files using the user's  
> authorities
> and logs all writes using the service's authorities.  All users have
> read authority on the log file.
>
> You have said that all that's needed is unforgeable authorities.  I'm
> simply stressing that the system must allow the programmer to express
> which authorities go with which designations.  You also said that.   
> I'm
> just suggesting that you keep these two statements together, since  
> it's
> possible to build a system that has one but not the other.

I agree. The reason why my two statements seem contradictory is that  
I refer to two different concepts of "system".

When I agree with you, that the "system" should allow the programmer  
to express which authorities go with which designations, I talk about  
that part of the system, on which the programmer must rely to make  
his code secure: the part that includes services like the ones in  
MyFileSystem.

As I  explained in my reply to David Hopwood, when I say that all  
that's needed in a "system", is unforgeable authority (that can be  
referenced and passed on), I'm talking about the protection system:  
the smaller constituent of the relied-upon part of the programming  
system, that controls authority at runtime, for untrusted code and  
relied-upon code alike. (The part that corresponds to reference  
monitors in ACL systems.)

While it matters a lot that untrusted code cannot forge authority, it  
does not matter at all that untrusted code can create confused  
deputies, because the programmer should not rely on it for security  
anyway.

cheers,
Fred.