[cap-talk] the "flaw" of separating designation from authority
fred at evoluware.eu
Fri Oct 27 03:22:53 CDT 2006
On 27 Oct 2006, at 00:52, David Hopwood wrote:
> Fred Spiessens wrote:
>> OK, I see, thanks for the explanation.
>> Yes, loosing the connection between the origin of the designation and
>> the origin of the authority will result in confused deputies. When
>> programming deputies, the ultimate advantage of capabilities is: that
>> you don't have to keep track of this connection yourself.
>> Programmers tend to keep track only of the designation
>> minded as they are), which is probably the reason why, in Client
>> Utility, they thought they could get away with combining
>> certificates, when they could not be sure that these certificates had
>> the same origin (certificates provided in the same invocation may be
>> of different origin).
>> 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 point is that losing track of this connection can only happen
> if and
> when the designation and the authority are separated.
>> The former would have indicated a flaw in
>> the system, while the latter is a programming error.
> I disagree. It's not sufficient just to make it possible for
> to avoid security vulnerabilities. Since a system consists of a large
> amount of code, the risk of an exploitable vulnerability per unit
> of code
> has to be very low indeed in order to yield a secure system. Just
> it possible to avoid vulnerabilities (given a great deal of
> attention to
> detail and exhaustive security review), will not achieve this. The
> approach that has a realistic chance of success is to make
> authorities-bundled-with designations (i.e. capabilities) the simplest
> and most obvious way of specifying any resource.
Identifying what is "theoretically possible" and "theoretically
impossible" is important, even when theoretically possible does not
always mean practically feasible.
This being said, there is also a practical aspect to my observation.
Let me paste back in the part of my mail that you left out, to make
sure that it is clear what we are talking about.
>> The only necessary condition for a system to allow a programmer to
>> protect his deputies from being confused is: that authority can
>> be passed as an unforgeable reference. The rest can, in principle,
>> be taken care of by the programmer (even if his job would have
>> been considerably simpler in a capability system).
>> Again, I do not exclude that other, more important flaws in Client
>> Utility style programs, indicate that real capabilities are
>> necessary, but capabilities are not strictly necessary to avoid
>> confused deputies (they are just most useful and efficient for
>> that purpose, and make programming much less error prone).
With a flaw in the system, I mean a flaw in the protection system
(e.g. as part of the runtime environment of a programming language).
I'm not talking about secure language design here.
Your objection can be taken care of by abstractions (e.g. provided in
a language library) that allow the programmer to combine a
certificate with a designation into a "pseudo-capability". The
language could even impose the use of "pseudo-capabilities", but the
runtime environment is not required to enforce this.
As for the untrusted code, the language runtime only has to enforce
that no authority is ambient, and that all authority is available
only in the form of unforgeable references (certificates), even when
these references do not function as designations. Similar to real
capability systems, the deputy can simply require his clients to
(But remember, I did not exclude that doing so could lead to other
vulnerabilities, I'm talking about confused deputies only. If you
know of any such vulnerabilities, please tell me.)
Both from a theoretical and a practical point of view, it is
important that we understand precisely what part of a capability
based protection system is really necessary, to prevent confused
More information about the cap-talk