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

[Fred Spiessens]

On 27 Oct 2006, at 04:47, Karp, Alan H wrote:

> Fred Spiessens wrote:
>>
>> The flaw is not "separating designation from authority" but "losing
>> track of the connection between the origin of the designation
>> and the
>> origin of the authority".  The former would have indicated a flaw in
>> the system, while the latter is a programming error.
>>
> Look at the example again (with the attack of specifying the log  
> file).
>
> The attacker invokes
>
> MyFileSystem.writeFile(fileID: 67890 certificate: Fcert1 data: "XYZ"
>
> which the service turns into
>
> MyFileSystem.logWriteFile(fileID: 67890 fileID: 67890 data: "XYZ"
> 			        certificates: Fcert1, Fcert2)
>
> Fcert1 comes from the attacker and allows writing of fileID: 12345.
> Fcert2 comes from the service and allows writing of fileID: 67890.   
> The
> system I described and participated in building :( had no mechanism  
> for
> matching up certs with arguments.  Since there is a cert that allows
> writing fileID: 67890, the log ends up with "XYZ".  Where is the
> programming error in the code that invokes logWriteFile?  The point is
> that this system doesn't provide a way for the programmer to keep the
> connection between the origin of the designation and the origin of the
> authority.

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?

That's a flaw in the design of the library that can render all  
efforts of the programmer to keep track of the link between (the  
origins of) authority and designation futile.
Clearly,  it could have been prevented without using capabilities, by  
designing the library like this:

logWriteFile(datafileID: 67890 logfileID: 67890 data: "XYZ"
		 datacertificat: Fcert1, logcertificat:   Fcert2)

If the problem would be down at the operating system level itself,  
then that flaw could be solved at that level in a similar way,   
without re-inventing capabilities.

The system not necessarily has to provide a way for the programmer to  
keep the connection between the origin of the designation and the  
origin of the authority. The programmer can do that himself, as long  
as the system does not impose libraries (or system calls) on him that  
render his efforts futile.

In practice, we know of course,  that solving the problem with  
capabilities  would automatically, once and for all, avoid that flaw,  
but that was not my point.

cheers,
Fred.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20061027/239b9285/attachment.html