[cap-talk] type safe language questions

[Ben Kloosterman]

A number of people have emailed me suggesting using references as
Capabilities.   This is attractive though I can see fine grained ACLs can
give more security than existing ACL environments ( eg Process + Assembly
would invalidate the Confused Deputy if the Reporting Engine was a separate
Assembly) it looks to me that for the price of unorthodoxy Capabilities will
give simplicity , better security and performance.

Using references as capabilities for .NET presents 2 issues 

Q1) How to store the access rights. 

Option1) 
Reference ->           File Class  ( with access via ACL)

Option2) 
Reference ->       Read Rights File wrapper Class  ->    file Class


Option3) 
Capability ( Reference + Rights)   -> File Class 

Looking at 2 vs 3 Comments on this in a Capability system .  The
Eros/Coyotos documentation seems to say a Capability is a right + an
unforgeable reference yet other people suggest it is just an unforgeable
reference ( ie Option 2) .


Q2) Unforgeable references. 

This requirement is quite interesting. Option 3 is unforgeable but Option 1
and Option2 allow the caller to change the reference to another valid
Capability the caller  possess of the same type ( note only the trusted code
can instantiate it and it must be the same Type) . For local variables and
parameters this is not an issue as you are specifying which file.   For more
complex objects it could be forgeable if the programmer is not careful.
Note only the owner of the Type can create the Reference we can do this by
having an internal constructor on a public class and hence it can only be
instantiated by the trusted code.

Eg 


Service1 -> Services2 -> Service3.

If the object being passed from Service 1 to Service 3 via Service 2 ,
Service 2 can change the reference .  

eg 
public class EncodeFileInformation
{
public ReadFile  SourceFile;
public WriteFile DestinationFile; 
}

Allows Service 2 to alter the request.

A better programmer could change this so the constructor sets the fields and
it is only available via get properties or read-only fields. 

public class EncodeFileInformation
{
public readonly ReadFile  SourceFile;
public readonly WriteFile DestinationFile; 
}

However this still leaves open the possibility of Service 2 stealing the
Capability ,though this should be covered by the "If you don't trust them
don't give them the key clause"

Do people think this is an issue ?  System Messages will obviously be
protected but new Capabilities could be more easily misused due to developer
error.

Regards,

Ben