Confused deputy

[Alan Karp]

Is there a proof that it's impossible to express a confused deputy vulnerability in a capability system?

(Asking for a colleague)

--------------
Alan Karp

[David Nicol]

Absolutely not, as counterexamples are easy to describe.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2kJG8HBW6ZO272jEb4kXHGDMP9s_w%3D47G5QNjw1dVU2Q%40mail.gmail.com.

--

"The profit motive is often in conflict with the aims of art." -- Ursula K. Le Guin

[Alan Karp]

Please give an example.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO_kHt-0ZCPoMHgriNP_rV5ZE9VwP9_iv%2B7WDNGX2rmN%2BA%40mail.gmail.com.

[Matt Rice]

I believe that the original confused deputy example can easily be
translated to use any key/value data structure like a hashmap,
basically without modification.
There are basically two things to note, the filesystem permissions
missing from the hashmap version were never triggered in the original
formulation of the problem,
and thus should not be of consequence. The original example didn't
use hierarchical features of the filesystem like multiple directories.
So the fact that a hashmap
acts like a single directory should be of no consequence.

As William said, basically just use some kind of map and designate
resources by name.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1SA7juTGuZMwidOayvJ2AhHeeWQ1xmmq72ZQAwp0KW6g%40mail.gmail.com.

[Alan Karp]

On Wed, Jul 22, 2026 at 7:10 PM Matt Rice <rat...@gmail.com> wrote:

As William said, basically just use some kind of map and designate
resources by name.

You prevent the vulnerability by only designating a resource with a capability to it.  Separating the two by using a name is the root cause of the vulnerability. 

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFpcAzDNw2nJjsZ3qFrRpD_t176h-gBHdHWm%2BHSYFDiidA%40mail.gmail.com.

[Matt Rice]

On Wed, Jul 22, 2026 at 7:16 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Wed, Jul 22, 2026 at 7:10 PM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> As William said, basically just use some kind of map and designate
>> resources by name.
>>
> You prevent the vulnerability by only designating a resource with a capability to it. Separating the two by using a name is the root cause of the vulnerability.
>

Short of getting rid of all forms of equality, how is one to prevent
designation by name? There is no prevention, just a convention which
shuns that.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z02iMczfCjeGVVs1ogbW5QY3j%3DagNtCaQuqXFe19nrByg%40mail.gmail.com.

[David Nicol]

The claim that is asked to be proven is "it's impossible to express a confused deputy vulnerability in a capability system."

Let's say Alice has access to resource R and wishes to share it with Bob and only Bob.

Alice crafts some kind of handle that provides such access and shares the handle with Bob but neglects to add the extra parts requiring Bob to authenticate as Bob before using it.

Mallory intercepts the handle and accesses the resource.

The handle is the deputy

The handle was confused in that it was used by Mallory not Bob

This vulnerability was expressed in a capability system.

Did I miss something?

On Wed, Jul 22, 2026 at 11:33 AM Alan Karp <alan...@gmail.com> wrote:

Please give an example.

--------------
Alan Karp

On Tue, Jul 21, 2026 at 9:52 PM David Nicol <david...@gmail.com> wrote:

Absolutely not, as counterexamples are easy to describe.

On Tue, Jul 21, 2026 at 7:26 PM Alan Karp <alan...@gmail.com> wrote:

Is there a proof that it's impossible to express a confused deputy vulnerability in a capability system?

(Asking for a colleague)

--------------
Alan Karp

--

[Alan Karp]

On Wed, Jul 22, 2026 at 7:24 PM Matt Rice <rat...@gmail.com> wrote:

Short of getting rid of all forms of equality, how is one to prevent
designation by name? There is no prevention, just a convention which
shuns that.

You can have a program that accepts a name and be vulnerable, or your program can accept only designation by capability and be safe.  You choose.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFqotB-%3DtuNiyqH0NN8p3u0NDokHzUJ9QLFURdgrNDU-%3DA%40mail.gmail.com.

[Alan Karp]

On Wed, Jul 22, 2026 at 7:56 PM David Nicol <david...@gmail.com> wrote:

The claim that is asked to be proven is "it's impossible to express a confused deputy vulnerability in a capability system."

My bad.  I stated the condition poorly.  It should have been something like, "it's impossible to express a confused deputy vulnerability in a system that only allows designation by capability."

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO8X%3Dtk1JyraPPyRspc6LHzv2%2Bf57gP2iGO2AEFZcaq2cA%40mail.gmail.com.

[Matt Rice]

On Wed, Jul 22, 2026 at 8:48 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Wed, Jul 22, 2026 at 7:56 PM David Nicol <david...@gmail.com> wrote:
>>
>> The claim that is asked to be proven is "it's impossible to express a confused deputy vulnerability in a capability system."
>>
> My bad. I stated the condition poorly. It should have been something like, "it's impossible to express a confused deputy vulnerability in a system that only allows designation by capability."
>

There really are very few systems able to isolate data channels from
capability channels to such a degree as to achieve this.
The only ones I know of being based upon concurrent separation logic
and running in theorem provers, not systems people run programs on.
Do any systems used in practice achieve the ability to forbid
designation by name via isolation of data channels from side-effects
or other means?

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1FRNC8AaKPAuxDbWZod%3DsYJc67RE_wBtD0-BDYCrRFYw%40mail.gmail.com.

[Matt Rice]

On Wed, Jul 22, 2026 at 9:05 PM Matt Rice <rat...@gmail.com> wrote:
>
> On Wed, Jul 22, 2026 at 8:48 PM Alan Karp <alan...@gmail.com> wrote:
> >
> > On Wed, Jul 22, 2026 at 7:56 PM David Nicol <david...@gmail.com> wrote:
> >>
> >> The claim that is asked to be proven is "it's impossible to express a confused deputy vulnerability in a capability system."
> >>
> > My bad. I stated the condition poorly. It should have been something like, "it's impossible to express a confused deputy vulnerability in a system that only allows designation by capability."
> >
>
> There really are very few systems able to isolate data channels from
> capability channels to such a degree as to achieve this.
> The only ones I know of being based upon concurrent separation logic
> and running in theorem provers, not systems people run programs on.
> Do any systems used in practice achieve the ability to forbid
> designation by name via isolation of data channels from side-effects
> or other means?

The other thing I should note is that I don't know how effective such
a thing would be in practice,
the mingling of data and authority is pretty strong. It is entirely
possible that it also prevents all useful
computation. Anyhow my point is what system achieves this, how does it
make it impossible to express?

[David Nicol]

On Wed, Jul 22, 2026 at 10:48 PM Alan Karp <alan...@gmail.com> wrote:

On Wed, Jul 22, 2026 at 7:56 PM David Nicol <david...@gmail.com> wrote:

The claim that is asked to be proven is "it's impossible to express a confused deputy vulnerability in a capability system."

My bad.  I stated the condition poorly.  It should have been something like, "it's impossible to express a confused deputy vulnerability in a system that only allows designation by capability."

Separate from the naming issues, problems can arise from correct designation and delegation of too large a grain of authority. Without getting formal about it, it seems that the power to deputize creates the power to create confusable deputies. Is Godel's incompleteness theorem a confused deputy vulnerability?

[Matt Rice]

On Wed, Jul 22, 2026 at 8:48 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Wed, Jul 22, 2026 at 7:56 PM David Nicol <david...@gmail.com> wrote:
>>
>> The claim that is asked to be proven is "it's impossible to express a confused deputy vulnerability in a capability system."
>>
> My bad. I stated the condition poorly. It should have been something like, "it's impossible to express a confused deputy vulnerability in a system that only allows designation by capability."
>

Sorry, let me try one last time to explain my problem with the way you
are expressing this:
AFAIK no-one knows a way to avoid introducing the possibility that
designation by name can be introduced through a data channel.
Derived from the designation by capability plus any associated data channels.

Even if you restrict the data channel to pure functions, and return a
`String -> Option<T>` and return `None` that's kind of introducing a
pure form of designation by name.

Then ascribe this as a property of the system, while it is a problem
of the usage of the system (or derived from it). While this statement
is effectively a tautology:
`It is impossible to express a confused deputy problem in systems
without confused deputy problems`.
Most if not all capability systems it is possible for an application
running on it to introduce designation by name without changing the
system.
That has been true for keykos, eros, coyotos, capros, sel4. Most of
these came with capabilities (directories) that provided designation
by name.
These should be closely held and discouraged from being shared. Their
usage is in UI where some form of designation by name is helpful, and
the problems
caused by it are uncommon, because this UI is not really a multi-party
program where this kind of problem can be exploited.
What system allows no mapping between names and capabilities, and in
it how does one differentiate any of their capabilities?
Systems can encourage usage of designation by capability, but
completely avoiding designation by name being derivable from data
channels and basic equality of data is very difficult
to avoid. Avoiding it by any simple means likely renders the system
unusable incapable of computation.

Saying that this or that isn't a capability system, because some
program on it contorted itself into designation by name is backwards,
and feeds this tautological definition.
It seems better to accept that capability systems can express confused
deputies, because you can do so without changing the system. Rather
than changing the definition
to avoid including these as capability systems. Because the system
doesn't change, two systems can be the same, but they become
capability systems or not based on usage.
We should avoid this because it would be surprising when people
discover they can in fact express confused deputies.

Anyhow systems like type and effect systems are why I waffle about
whether or not it is possible to have systems where it is impossible
to derive designation by name.
Certainly I don't think any existing system has managed it, but
perhaps they can certainly keep the capabilities and any associated
data channel's intertwined by the parameterized effect type.
Then we can effectively show that names on one channel, and names on
the other channel are effectively disjoint . But we can probably
ignore these for the purposes of this discussion,
as I don't really know of any capability systems of this form.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1FRNC8AaKPAuxDbWZod%3DsYJc67RE_wBtD0-BDYCrRFYw%40mail.gmail.com.

[John Carlson]

So this might not be considered confused deputy.   Using the key analogy, you might give a ring full of keys to a deputy, and a bunch of doors.  Then you tell the deputy not to unlock a door with the hungry tiger behind it, without any designations, no identification or labeling of any door with a hungry tiger behind it.  I think the only way for the deputy to remain non-confused and alive is by not opening any doors, leaving the keys unusable.   So a capability system without anyone wanting to use it, unless a resource is provided to feed the tiger.  Okay, someone can put this in fancy terminology.

[Alan Karp]

On Wed, Jul 22, 2026 at 9:06 PM Matt Rice <rat...@gmail.com> wrote:

There really are very few systems able to isolate data channels from
capability channels to such a degree as to achieve this.

The only ones I know of being based upon concurrent separation logic
and running in theorem provers, not systems people run programs on.
Do any systems used in practice achieve the ability to forbid
designation by name via isolation of data channels from side-effects
or other means?

Forbidding designation by name doesn't have to be done via isolation of data channels.  For example, the zcap spec uses capability certificates for designation, which means it forbids separating designation from authorization. 

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFoT_cLHhABdUo7D%3D-wJoNjcmiNX0W6%3Dt%2BjOwC4u8mggHA%40mail.gmail.com.

[Alan Karp]

On Thu, Jul 23, 2026 at 1:28 AM David Nicol <david...@gmail.com> wrote:

allows designation by capability."

Separate from the naming issues, problems can arise from correct designation and delegation of too large a grain of authority.

Yes, but granting too much authority is a different problem.

 

Without getting formal about it, it seems that the power to deputize creates the power to create confusable deputies. Is Godel's incompleteness theorem a confused deputy vulnerability?

True if "confusable" is a general concept.  In this context, "confusable" only means using the deputy's permissions on a resource designated by someone else.

--------------
Alan Karp

[Alan Karp]

On Thu, Jul 23, 2026 at 10:04 AM John Carlson <yott...@gmail.com> wrote:

So this might not be considered confused deputy.   Using the key analogy, you might give a ring full of keys to a deputy, and a bunch of doors.  Then you tell the deputy not to unlock a door with the hungry tiger behind it, without any designations, no identification or labeling of any door with a hungry tiger behind it.  I think the only way for the deputy to remain non-confused and alive is by not opening any doors, leaving the keys unusable.   So a capability system without anyone wanting to use it, unless a resource is provided to feed the tiger.  Okay, someone can put this in fancy terminology.

Keyrings are how I managed to introduce a confused deputy vulnerability into the Client Utility design.  Fortunately, they only existed as an optimization.

I think a better example is the building supervisor with keys to all the apartments.  You tell her you're locked out of your apartment, and she opens the door for you.  The supe is a confused deputy; she has used her key (permission) to access an apartment (resource) that you designated.

--------------
Alan Karp

[Alan Karp]

On Wed, Jul 22, 2026 at 9:21 PM Matt Rice <rat...@gmail.com> wrote:

The other thing I should note is that I don't know how effective such
a thing would be in practice,
the mingling of data and authority is pretty strong. It is entirely
possible that it also prevents all useful
computation. Anyhow my point is what system achieves this, how does it
make it impossible to express?

The API can accept only a capability to designate a resource.  That's what's done in ocap languages; the API accepts an object reference as an argument, not a string naming the object.  The same applies to certificates as capabilities.  A zcap invocation requires that you designate the resource with the capability certificate authorizing its use.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFpDLYDf%3DFMMD7BP1wOhfCAarfMrcMEjgC1cRLiHx8goDQ%40mail.gmail.com.

[Matt Rice]

On Thu, Jul 23, 2026 at 10:29 AM Alan Karp <alan...@gmail.com> wrote:
>
> On Wed, Jul 22, 2026 at 9:21 PM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> The other thing I should note is that I don't know how effective such
>> a thing would be in practice,
>> the mingling of data and authority is pretty strong. It is entirely
>> possible that it also prevents all useful
>> computation. Anyhow my point is what system achieves this, how does it
>> make it impossible to express?
>
>
> The API can accept only a capability to designate a resource. That's what's done in ocap languages; the API accepts an object reference as an argument, not a string naming the object. The same applies to certificates as capabilities. A zcap invocation requires that you designate the resource with the capability certificate authorizing its use.
>

How does one enforce this? If your system is entirely devoid of all
forms of data and can only invoke capabilities for their effects it
isn't useful.
If you're using certificates, rather than a shared map structure maybe
the confused deputy involves credential sharing. These are logical
errors as a consequence of
using the system wrong. They cannot be solved by describing the rules
unless those rules can be actually enforced.

One of the important distinctions when comparing these kinds of
systems should be, how difficult is it to get the rules wrong.
How much effort must one put in to do the wrong thing, compared to how
easy it is to do the right thing.
In the capability model it's generally been much easier to just do the
right thing, than to build a contraption which does
the wrong thing. I have zero intuition on where that balance sits on
certificate systems because I care little about them.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1DJcbZWkySjxRR%2B-ecOHHOSNG5jG5nnavrENY7HNa4Dg%40mail.gmail.com.

[Alan Karp]

Having built UIs for several capability-based projects, I feel I can say that you can enforce designation by capability.  In SCooPFS, the user saw strings in the UI, but every click selected the corresponding Waterken YURL, which is what was sent in the API call.  There was no way to express a confused deputy attack.

My first question was indeed saying, "Saying that this or that isn't a capability system, because some program on it contorted itself into designation by name,"  which is why I revised it to say, "There is no confused deputy vulnerability if designation is always combined with authorization."  You can certainly build, and I have inadvertently built, a capability system that doesn't do that.

 

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFpHSrGM9SQKN0B0%3DurKvT5Rb8Eq%3D7p_6sAJ6EnNW-gQoA%40mail.gmail.com.

[Alan Karp]

On Thu, Jul 23, 2026 at 10:39 AM Matt Rice <rat...@gmail.com> wrote:

How does one enforce this? If your system is entirely devoid of all
forms of data and can only invoke capabilities for their effects it
isn't useful.
If you're using certificates, rather than a shared map structure maybe
the confused deputy involves credential sharing. These are logical
errors as a consequence of
using the system wrong. They cannot be solved by describing the rules
unless those rules can be actually enforced.

I don't think credential sharing has anything to do with confused deputy.

You protect yourself from confused deputy attacks by having an API for your services that only accepts a capability as a resource designation. You can always design a system that doesn't (as I once did).

One of the important distinctions when comparing these kinds of
systems should be, how difficult is it to get the rules wrong.
How much effort must one put in to do the wrong thing, compared to how
easy it is to do the right thing.
In the capability model it's generally been much easier to just do the
right thing, than to build a contraption which does
the wrong thing. I have zero intuition on where that balance sits on
certificate systems because I care little about them.

That's a good point.  One reason I review so many designs is to point out when they are doing the wrong thing, which I've learned is all too easy.  Still, the fact that it's easy to design a system with the vulnerability, doesn't negate the fact that it's possible to get it right. 

Note that I'm talking about the design of the system, not its use.  No use of a system that always combines designation with authorization can trigger a confused deputy vulnerability.  That doesn't mean it's secure, just that it's safe from this one attack.

 

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFrPHHMbWksLoWyAiFan05mrdEdmxOwX%3DqGQQT1bEw-nKA%40mail.gmail.com.

[David Nicol]

On Thu, Jul 23, 2026 at 12:13 PM Alan Karp <alan...@gmail.com> wrote:

Yes, but granting too much authority is a different problem.

Is it? Is this not the "principle of least authority" mailing list? 

Does not "confused deputy vulnerability" arise from "granting too much authority" ?

Thanks for letting me be part of this discussion, I'm going to try to shut up and lurk now.

 

[Matt Rice]

On Thu, Jul 23, 2026 at 10:40 AM Alan Karp <alan...@gmail.com> wrote:
>
> Having built UIs for several capability-based projects, I feel I can say that you can enforce designation by capability. In SCooPFS, the user saw strings in the UI, but every click selected the corresponding Waterken YURL, which is what was sent in the API call. There was no way to express a confused deputy attack.
>
> My first question was indeed saying, "Saying that this or that isn't a capability system, because some program on it contorted itself into designation by name," which is why I revised it to say, "There is no confused deputy vulnerability if designation is always combined with authorization." You can certainly build, and I have inadvertently built, a capability system that doesn't do that.
>

It isn't clear to me in this case whether you are talking about a
general purpose system, or a complete system with a fixed set of
capabilities.
I agree that you can design a complete system, with a fixed set of
capabilities where there is no confused deputy.
The problems I think we've been discussing are whether you can provide
a base capability system, onto which you deploy programs and processes
composed of capabilities written by a third party,
where the base system somehow keeps the 3rd party capabilities from
introducing confused deputies.

I'm of the there is nothing the base system can provide which allows
it to be used as a general purpose system which doesn't also open
itself up to being misused by introducing
a confused deputy via a 3rd party downstream programmer writing some
nonsense (This doesn't have to be any of the parties involved in the
usage of the system).

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2TP-WeSAGKW5F_8kDUNoJ_93yomvriy0kdqhmV_BUCHg%40mail.gmail.com.

[Alan Karp]

On Thu, Jul 23, 2026 at 11:00 AM David Nicol <david...@gmail.com> wrote:

Is it? Is this not the "principle of least authority" mailing list? 

Yes, but that topic has nothing to do with confused deputy.

Does not "confused deputy vulnerability" arise from "granting too much authority" ?

No.  The deputy needs all the authority it has.  In Norm's example, the deputy needs permission to write the billing file.

Thanks for letting me be part of this discussion, I'm going to try to shut up and lurk now.

Don't just lurk.  Your comments are valuable.

  

--------------
Alan Karp

[Matt Rice]

On Thu, Jul 23, 2026 at 11:00 AM David Nicol <david...@gmail.com> wrote:
>
>
>
> On Thu, Jul 23, 2026 at 12:13 PM Alan Karp <alan...@gmail.com> wrote:
>>
>>
>>
>> Yes, but granting too much authority is a different problem.
>
>
>
> Is it? Is this not the "principle of least authority" mailing list?
>
> Does not "confused deputy vulnerability" arise from "granting too much authority" ?
>
> Thanks for letting me be part of this discussion, I'm going to try to shut up and lurk now.
>

This is exactly the point I was trying to make in the comparing
credential sharing in certificate systems to
granting too much authority in capability systems:

If we take a really dumb example of the `store capabilities in a map`,
we're basically saying

```
map.insert("bob.secret", "...");
map.insert("alice.secret", "...")

alice.grant(map);
bob.grant(map);
alice.tell("I put a secret in the map alice.secret");
bob.tell("I put a secret in the map bob.secret");
// Expect alice and bob not to check for files with the others name.
```

>
> --
> "The profit motive is often in conflict with the aims of art." -- Ursula K. Le Guin
>

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO8YcW856qr%2Bo2e_rrdZYs8_3OLePJcGL79nNV-WHF4vrg%40mail.gmail.com.

[Mark S. Miller]

On Thu, Jul 23, 2026 at 11:05 AM Matt Rice <rat...@gmail.com> wrote:

On Thu, Jul 23, 2026 at 11:00 AM David Nicol <david...@gmail.com> wrote:
>
>
>
> On Thu, Jul 23, 2026 at 12:13 PM Alan Karp <alan...@gmail.com> wrote:
>>
>>
>>
>> Yes, but granting too much authority is a different problem.
>
>
>
> Is it? Is this not the "principle of least authority" mailing list?
>
> Does not "confused deputy vulnerability" arise from "granting too much authority" ?

No. The only thing they have in common is that ocaps are the antidote.

>
> Thanks for letting me be part of this discussion, I'm going to try to shut up and lurk now.
>

This is exactly the point I was trying to make in the comparing
credential sharing in certificate systems to
granting too much authority in capability systems:

If we take a really dumb example of the `store capabilities in a map`,
we're basically saying

```
map.insert("bob.secret", "...");
map.insert("alice.secret", "...")

alice.grant(map);
bob.grant(map);
alice.tell("I put a secret in the map alice.secret");
bob.tell("I put a secret in the map bob.secret");
// Expect alice and bob not to check for files with the others name.
```

>
> --
> "The profit motive is often in conflict with the aims of art." -- Ursula K. Le Guin
>
> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO8YcW856qr%2Bo2e_rrdZYs8_3OLePJcGL79nNV-WHF4vrg%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFq%2BoTd5K7EzQRNJDqoQqa8TMxfQMFaCygrDw2ad84yeFA%40mail.gmail.com.

[Matt Rice]

On Thu, Jul 23, 2026 at 11:25 AM 'Mark S. Miller' via cap-talk
<cap-...@googlegroups.com> wrote:
>
>
>
> On Thu, Jul 23, 2026 at 11:05 AM Matt Rice <rat...@gmail.com> wrote:
>>
>> On Thu, Jul 23, 2026 at 11:00 AM David Nicol <david...@gmail.com> wrote:
>> >
>> >
>> >
>> > On Thu, Jul 23, 2026 at 12:13 PM Alan Karp <alan...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> Yes, but granting too much authority is a different problem.
>> >
>> >
>> >
>> > Is it? Is this not the "principle of least authority" mailing list?
>> >
>> > Does not "confused deputy vulnerability" arise from "granting too much authority" ?
>
>
> No. The only thing they have in common is that ocaps are the antidote.
>

Perhaps instead of "granting too much authority", we could replace that with
"unintended sharing of excess authority", since granting pretty much
implies authorization?
Anyhow that was the spirit in with which I agree with David.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD7fWsb6DPfDZQfJTnKcHFm016svb%3DDs_xg2uuUd8-cP3w%40mail.gmail.com.

[Mark S. Miller]

Perhaps instead of "granting too much authority", we could replace that with
"unintended sharing of excess authority", since granting pretty much
implies authorization?

But it is not excess. In the compiler example, the compiler must be permitted to write to the log file.

It is unintended sharing. But not because anyone is confused.

[Matt Rice]

I meant excess from the perspective of the user invoking the compiler.
Assuming they have authority to write to all the places they can write,
they also were unintentionally capable of reaching an additional
permission to write to the log file.
That is to say I intended excess to mean the transitive reachability
of the log file.
But I respect the point, from the complete object graph the permission
is not excess.

>
> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAK-_AD5SkrbwbcwjyH5iQo5BTWV3EShc-9ob4%3D6boQMHeAwpyw%40mail.gmail.com.

[Alan Karp]

On Thu, Jul 23, 2026 at 11:03 AM Matt Rice <rat...@gmail.com> wrote:

It isn't clear to me in this case whether you are talking about a
general purpose system, or a complete system with a fixed set of
capabilities.

I'm talking about a way to write your code so it's not vulnerable to confused deputy.

 

I agree that you can design a complete system, with a fixed set of
capabilities where there is no confused deputy.

What do you mean by "a fixed set of capabilities"?  It should always be possible to create new resources and the capabilities that grant access to them.

 

The problems I think we've been discussing are whether you can provide
a base capability system, onto which you deploy programs and processes
composed of capabilities written by a third party,
where the base system somehow keeps the 3rd party capabilities from
introducing confused deputies.

A third party who doesn't apply the discipline to its code may be vulnerable.  There's nothing the base system can do to help.  However, invocations of the base system are not vulnerable even if third party code is.

I'm of the there is nothing the base system can provide which allows
it to be used as a general purpose system which doesn't also open
itself up to being misused by introducing
a confused deputy via a 3rd party downstream programmer writing some
nonsense (This doesn't have to be any of the parties involved in the 

usage of the system).

A 3rd party programmer can do arbitrary stupid things, but those things should only harm that programmer or the people who use those programs.  If you only allow designation by authorization, you are safe from confused deputy.  Permissions you've granted to others may be vulnerable if the program using them isn't properly constructed.  You need a way to hold them responsible for misuse, whether it's intentional or because of a confused deputy.

 

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFqz7jz4%2B0AnXjjmZoG0Hd%3DH%2BQM%2BHUnpZc%2BFqR4N6-UOyw%40mail.gmail.com.

[Matt Rice]

On Thu, Jul 23, 2026 at 3:55 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Thu, Jul 23, 2026 at 11:03 AM Matt Rice <rat...@gmail.com> wrote:
>>
>>
>> It isn't clear to me in this case whether you are talking about a
>> general purpose system, or a complete system with a fixed set of
>> capabilities.
>
>
> I'm talking about a way to write your code so it's not vulnerable to confused deputy.

Makes sense, I've been and I presume the others that were talking
about it being possible to derive a confused deputy problem
within a capability system, were saying something to the effect of:

"Is it possible using any and all primitives available within the base
system to derive a confused deputy problem", to which the answer is
yes.
If you change that to "Is it possible using any and all primitives
available within the base system while following the guidelines set
forth by Alan" then the answer
may well be no.

>
>>
>> I agree that you can design a complete system, with a fixed set of
>> capabilities where there is no confused deputy.
>
>
> What do you mean by "a fixed set of capabilities"? It should always be possible to create new resources and the capabilities that grant access to them.

I believe that coyotos called it a system image, and keykos the "big
bang", an initial set of capabilities from which bootstrapping occurs.

What I essentially mean is a system where no additional programmer
text can be included, i.e. you start out with a base system which does
not include
a confused deputy, assuming you have a proof that it is impossible to
derive a confused deputy from the initial set of capabilities, then
you should not be able to derive a confused deputy
without adding any new capabilities from which you can derive a confused deputy.

In logic these are the differences between "admissability", and
"derivability", admissability being a weaker property, which can be
broken by the admission of new capabilities.
If you add new rules or capabilities, you should still be able to
derive any previous derivations from the unchanged capabilities that
were previously used to derive the property.
However, if you admit new rules or capabilities, you may be able to
derive new properties that were admitted by the new rules or
capabilities.

Operating systems like, used to execute unknown programs, suffer from
admissability problems, An OS which previously did not contain a
confused deputy in the base system
can have one added to it by admitting a new program that contains one.

That is to say, it may be possible to admit a new capability in the
base system that contains a confused deputy, and despite that it may
be impossible to derive
a new capability that contains a confused deputy from any existing one.

The point is that absence of confused deputy problems can only be
shown for closed system, while a lot of capability systems people use
are open.

>
>>
>> The problems I think we've been discussing are whether you can provide
>> a base capability system, onto which you deploy programs and processes
>> composed of capabilities written by a third party,
>> where the base system somehow keeps the 3rd party capabilities from
>> introducing confused deputies.
>
>
> A third party who doesn't apply the discipline to its code may be vulnerable. There's nothing the base system can do to help. However, invocations of the base system are not vulnerable even if third party code is.
>>

It kind of sounds like we're in violent agreement then.

>>
>> I'm of the there is nothing the base system can provide which allows
>> it to be used as a general purpose system which doesn't also open
>> itself up to being misused by introducing
>> a confused deputy via a 3rd party downstream programmer writing some
>> nonsense (This doesn't have to be any of the parties involved in the
>>
>> usage of the system).
>
>
> A 3rd party programmer can do arbitrary stupid things, but those things should only harm that programmer or the people who use those programs. If you only allow designation by authorization, you are safe from confused deputy. Permissions you've granted to others may be vulnerable if the program using them isn't properly constructed. You need a way to hold them responsible for misuse, whether it's intentional or because of a confused deputy.

Sure, the point is that a capability system isn't magic dust you can
sprinkle over your program and use to avoid discipline, if you're
going to prove the absence of a confused deputy on an open system
you'll need to do it by constructing it via a closed set of rules like
you have. I think part of the problem is we don't really have a type
checker, or any static validation that can tell us whether or not a
system was built following the rules, because confused deputy problems
are logic errors.
I feel at least like I better understand the disconnect...

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1nvEDYmBPTpE3nRM7d9WWTAQk%3DgKhJn0h-sCbEY_kSdA%40mail.gmail.com.

[Alan Karp]

A lot to comment on, but I think I can summarize by saying that you can avoid the confused deputy vulnerability by only allowing a resource to be designated by a capability to it.  It doesn't matter when, where, or how the capability was created.  If you want to use that resource, you must designate it with one of the capabilities you hold.

Now back to my original question.  Is there a proof?

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFpBMzNw9mZWM2X7%2Bi66o4Fn05koR-KchesNp-N1V6k0Bg%40mail.gmail.com.

[Matt Rice]

On Thu, Jul 23, 2026 at 4:57 PM Alan Karp <alan...@gmail.com> wrote:
>
> A lot to comment on, but I think I can summarize by saying that you can avoid the confused deputy vulnerability by only allowing a resource to be designated by a capability to it. It doesn't matter when, where, or how the capability was created. If you want to use that resource, you must designate it with one of the capabilities you hold.
>
> Now back to my original question. Is there a proof?
>

I don't entirely agree with your summary "it doesn't matter how"
particularly... It matters that the capability respects some
properties.
While I don't know of a proof, I don't know of a counterexample either.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z20vBCwo0g9E92%2BtZcCkdfDsOtu1YQrdp-tHMCr_HeOuw%40mail.gmail.com.

[David Nicol]

How about, we turn the question around and try describe the characteristics of System K (for Karp) in which it can be proven that (outside of deliberate misuse or social engineering -- if you hand your car key to a thief who steals your car, that isn't the key's fault, or the car's, or possibly even yours) a confused deputy vulnerability is impossible to create by accident, and see where we get.

This conversation of the last few days has identified at least two sources of vulnerability, the naming vulnerability, which involves referring to resources by name instead of a genuinely unique identifier, highlighted by Matt Rice, and the overdelgation vulnerability, which involves delegating a larger scope of authority than what is strictly required to let the delegee do their assignment, highlighted by myself.

We presume a robust authentication framework. For Op256, I've chosen ed25519 signing, but "a robust authentication framework" is what is required at this level of design.

We presume a robust designation framework. For Op256, I've chosen Blake3 hashes of combinations of other Blake3 hashes and ed25519 public keys and also literals, but "robust designation framework" is what is required at this level of design.

We presume both resources and operations on resources are designated using the designation framework, getting inside the whole "handle to the object means access to all the object's methods" discussion. Bundling is a distraction at this level of design.

I'm not here to sell Op256. (well at least not this week.) Or even to compare and contrast "message passing" against "method calling" as a metaphor. Those things are implementation details at this level of design.

About the overdelegation risk: System K must have a way to delegate an operation on a designated resource to a delegee, so that the authenticated delegee may use the delegation to do the operation on the resource. An example of doing an operation on a resource would be something like "rewrite one particular paragraph of a document". The delegation crafting mechanism needs to support arbitrarily fine-grained (or, conversely, coarse-grained) granting/sharing of authority. 

"grant" seems more natural for operations that can make changes, while "share" seems more natural for read-only operations -- like, being able to read the rest of the document to get context to guide the editing of the assigned paragraph. They are identical at this level of design as they are both ways to allow someone else to also be able to do something the granter/sharer can do without allowing them to do everything the granter/sharer can do. That's called "rights attenuation" here, I think, although I hate the word "attenuation" because it makes me think of radios and I generally miss the rest of the conversation. Like, superhetrodyne frequency modulation, not some Linux distribution named by abbreviating "radical operating system" into "RadiOS" which is entirely believable and I wouldn't be surprised if it hasn't been done and I'm not checking. Okay I'll check.

But anyway.

And the data structures involved in the work (here, a document editing system) need to provide the arbitrary-grained authority scoping. And we surely want snapshotting, rollback, the whole range of patch merging semantics.

About the naming risk: System K must have a way to communicate the delegation so that the receiver may inspect the delegation to see what it gives them the authority to do, without calling, running, executing, exercising, or anything, the delegation. Otherwise, a bad actor can misrepresent the wrong delegation and do bad things.

And delegations need to declare if they can be re-delegated, or not, and when they expire, and if they survive version upgrades, and so on.

The rest of the stroll through the garden of thought to maybe arrive at System K would include describing "confused deputy problem" using [identity, delegation, resource, attenuation, other words] and then design System K and its allowed uses to fit. At that point, instead of asking "Does (a capability system) prevent confused deputy vulnerabilities within a reasonable definition of completely" which is troublesome as there are so many of them, we can ask about each capability system, "is this system conformant with System K?" without the discussion degenerating into either violent agreement or advocating why any particular capability system is the best.

I think that approach might result in a rigorous proof, but I'm an uncredentialed autodidact when it comes to this stuff. 

I don't know if all the characteristics I enumerated above are needed, or what other characteristics are required.

And I'm saying "delegations" instead of "capabilities" to maintain distance from existing work, for abstraction purposes. It seems safe to choose some reasonable axioms like "resources have owners, who may delegate full or partial access to them" without getting into the weeds of owner governance procedures and the tension between consensus and autonomy.

On Thu, Jul 23, 2026 at 6:57 PM Alan Karp <alan...@gmail.com> wrote:

A lot to comment on, but I think I can summarize by saying that you can avoid the confused deputy vulnerability by only allowing a resource to be designated by a capability to it.  It doesn't matter when, where, or how the capability was created.  If you want to use that resource, you must designate it with one of the capabilities you hold.

Now back to my original question.  Is there a proof?

--------------
Alan Karp

[Alan Karp]

You raise a lot of important issues relevant to designing a secure system, almost none of them relevant to the confused deputy vulnerability.  My focus is on that very small part of the security problem.  

Combining designation with authorization allows the deputy to use its permissions for resources the deputy designates and its client's permissions for the resources the client designates.  My intuition says that's sufficient to enable you to code a deputy that will not use its permissions for a resource designated by one of its clients.  My colleague is asking for something more formal.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO-TpbtOKGfodWhssx2V7MhNKi%2BaTSJ6tarR0u%2BY8tbK1g%40mail.gmail.com.

[Matt Rice]

Well the basic sketch I came up with is to note that "Do not separate
designation from authority" is creating bijective mapping between
designation and authority.
Where each party contributes one designation, and one authority for
each capability contributed to the invocation.
A confused deputy primarily occurs through a surjective mapping where
multiple parties each designate the same authority in an "onto"
fashion,
or "excess authority" (injectivity) where an authority is not designated.

Taking the transitive closure of authorities within it then should
build a mapping where each authority is designated exactly once.
with each party designating exactly the set of resources they contributed.
This isn't really formal, but it seems formalizable, with the whole
machinery for building the transitive closure of an invocation
probably being the most involved...

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z20vBCwo0g9E92%2BtZcCkdfDsOtu1YQrdp-tHMCr_HeOuw%40mail.gmail.com.

[Matt Rice]

On Thu, Jul 23, 2026 at 10:35 PM Matt Rice <rat...@gmail.com> wrote:
>
> Well the basic sketch I came up with is to note that "Do not separate
> designation from authority" is creating bijective mapping between
> designation and authority.
> Where each party contributes one designation, and one authority for
> each capability contributed to the invocation.
> A confused deputy primarily occurs through a surjective mapping where
> multiple parties each designate the same authority in an "onto"
> fashion,
> or "excess authority" (injectivity) where an authority is not designated.
>
> Taking the transitive closure of authorities within it then should
> build a mapping where each authority is designated exactly once.
> with each party designating exactly the set of resources they contributed.
> This isn't really formal, but it seems formalizable, with the whole
> machinery for building the transitive closure of an invocation
> probably being the most involved...

Probably some missing bit in there about freshness, each capability
should be fresh
in the sense that if the same capability is designated multiple times
each designation
produces it's own fresh mapping as though they were separate
capabilities entirely.

[Alan Karp]

Sounds like you're on the right track, but I don't have the math chops to know for sure.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFrvfWF0e2ibDbHGo9oyr6ZH%3DioSwjHZi9o5Bf-iCEUixQ%40mail.gmail.com.

[Matt Rice]

FWIW I figured I should probably at least try and explain how it
relates to the confused deputy,
essentially we want to enumerate the list of reachable capabilities,
and ensure that each one was passed
as some form of parameter via invocation or otherwise via the various
means of connectivity described in MarkM's
thesis corresponds to exactly one designation. If there are
capabilities not designated (excess authority),
or capabilities designated which weren't provided by the designation
it must involve some form of reference to a captured capability
reference, exactly what we want to avoid in the confused deputy.

Anyhow it feels reasonable to me too...

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3W8qzdF%2BFCvkcSbm5Ce6FwzvKunPkwqUGQ4t_wDKH3zQ%40mail.gmail.com.

[Raoul Duke]

I feel like that is a universal cap "reductio" concern: One has to ask, how does any object (eg deputy) get instantiated, specifically where do its own caps come from?

If you ignore that and assume they are safe/valid, and if the requirement is just that the deputy only use the luser's caps, that seems to me to boil down to plain old code inspection - that no silly mistakes exist in the deputy's code.

[Alan Karp]

I would say that the type of the arguments in the API is important.  Any argument that designates a resource must be a capability.  That makes the code inspection job much easier.

--------------
Alan Karp

On Fri, Jul 24, 2026 at 9:46 AM Raoul Duke <rao...@gmail.com> wrote:

I feel like that is a universal cap "reductio" concern: One has to ask, how does any object (eg deputy) get instantiated, specifically where do its own caps come from?

If you ignore that and assume they are safe/valid, and if the requirement is just that the deputy only use the luser's caps, that seems to me to boil down to plain old code inspection - that no silly mistakes exist in the deputy's code.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAJ7XQb68Vcd2t2amZ8XWUn_PCm1PEBW7nSQJeGLPu%3DRvhGqeuA%40mail.gmail.com.

[David Nicol]

I'm guessing the actual problem the colleague is working on is safely trusting dry agents with budgets, like AI concierges? I've read nightmare stories about booking rooms in hotels far from the beach.

On Thu, Jul 23, 2026 at 9:38 PM Alan Karp <alan...@gmail.com> wrote:

Combining designation with authorization allows the deputy to use its permissions for resources the deputy designates and its client's permissions for the resources the client designates.  My intuition says that's sufficient to enable you to code a deputy that will not use its permissions for a resource designated by one of its clients.  My colleague is asking for something more formal.

 

[Matt Rice]

On Fri, Jul 24, 2026 at 9:46 AM Raoul Duke <rao...@gmail.com> wrote:
>

> I feel like that is a universal cap "reductio" concern: One has to ask, how does any object (eg deputy) get instantiated, specifically where do its own caps come from?
>
> If you ignore that and assume they are safe/valid, and if the requirement is just that the deputy only use the luser's caps, that seems to me to boil down to plain old code inspection - that no silly mistakes exist in the deputy's code.
>

Here was a recent confused deputy, in a kind of important
authentication system...
despite that it went through multiple rounds of review before even
being accepted as a bug.

https://weirdmachine64.github.io/research/google-oauth-device-code-hijacking.html

I feel like some kind of static analysis tool should not be unwelcome...

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAJ7XQb68Vcd2t2amZ8XWUn_PCm1PEBW7nSQJeGLPu%3DRvhGqeuA%40mail.gmail.com.

[Raoul Duke]

> google auth bugs

but would that be considered a real cap system?

("no true scotsman" is bad, i know, i know)

[Matt Rice]

If so not a very good one, but by a company that has
written/participated in multiple capability systems,
kataOS, fuchsia, who knows what else. One would expect that at
critical points like authentication they might learn a lesson or two
from their adjacency
to capability system projects? If someone should know...

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAJ7XQb6o1s15ac1fS5TU1nubEjU2n12QGdbsT%2BV2rVQewnmXLQ%40mail.gmail.com.

[Alan Karp]

Actually, he claims to have a mathematically rigorous proof that his system is immune to confused deputy.  He's asking for the same for capabilities. 

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAFwScO_9HXFjBnp9Uwi5Hh6HdqFe3WkKmqfRmOe2Y8UxJgHduA%40mail.gmail.com.

[Alan Karp]

Having worked at companies that size, it's highly unlikely that the authentication team was aware of those other projects.

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFpXcMorvR1qxB5fH0s4LeZnU7z5_T%2BRbJwyFeGGwMftBw%40mail.gmail.com.

[Alan Karp]

Not being a formal methods person has gotten me in trouble yet again.  I have now stated the premise poorly twice.  Is the third time the charm?

The key word in my question is vulnerability.  Vulnerability says to me that there is some way an adversary can use a program to produce a result the program would not produce absent the attack.  In the classic example, that's overwriting the billing file with the compiler output.  Note that a bug in the program could cause that to happen, but that's not what I'm calling a vulnerability

For the confused deputy vulnerability, we start with a program that produces a correct result given correct inputs.  The vulnerability we're interested in involves the adversary providing malicious designation of a resource input.  In the classic example, the adversary designates the billing file for the place to put the compiler output.

With those conditions, is it possible to prove that combining designation with authorization prevents the attack from succeeding?

--------------
Alan Karp

[Matt Rice]

The way I'd try to go about describing (parts of it) is something like:
there does not exist a designation that the caller can provide that
designates an authority that the caller itself did not also provide.
At least that was the way I was attempting to approach it.

> --
> You received this message because you are subscribed to the Google Groups "cap-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3Gm_2aY%2B-4ekU3Qfhxo31%2B3%2BZQPhryHFo9FnNbtR4CDg%40mail.gmail.com.

[Alan Karp]

That's the essence.  Now for a formal proof. 

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CACTLOFram6RE-hAFA0vAu4zcu_X-f-kUfVHZNNN%2BRQJQh2MV4g%40mail.gmail.com.

[Matt Rice]

Well, apologies but I probably shouldn't spend a whole lot more time on it.
Already a bit behind on other projects.

I know there has been some formal verification projects adjacent to of
capability patterns
in the iris prover at iris-project.org and perhaps also some in lean 4
from the scala
adjacent people like https://reservoir.lean-lang.org/@Linyxus/capless
plus some other
projects I see references to but haven't found.

There is probably a lot you can trim if not doing a whole language
soundness proof though.
*shrug*

> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0eUWEGD9YC0VHpRmrNYuumPkScwGzH79yehGkYBMuaJQ%40mail.gmail.com.

[Jonathan S. Shapiro]

There is a (hypothetical) generalized counterexample that mildly concerns me.

Confinement in capability-based systems is not just about leakage. It’s also about a less discussed problem, which might be described as “the only in-bound path for communication is the IPC receive path, which bounds the attack surface and renders it software-defensible. I haven’t seen that presented well, so maybe it’s worth a paper somewhere. Another Note on the Confinement Problem? Tempting. 

When Butler described the confinement problem, he did not consider of covert channels or side channels. He then objected to our verification proof on covert channel grounds, which we had acknowledged.

So far as I’m aware, up to overt channels, a confused deputy can only be expressed through a software logic error in the implementing agent. Most (but probably not all) of these can be validated by model checking techniques similar to what Hap Chen did with MOPs.

The unknown in my mind is whether a “reverse” side channel attack can induce such a logic error in the implementing agent. 

I have no idea what the answer is, but hair dryers have led me to marginally(?) greater humility. Or at least to cutting my hair short enough that I don’t use one.:-)

Jonathan

On Tue, Jul 21, 2026 at 5:26 PM Alan Karp <alan...@gmail.com> wrote:

Is there a proof that it's impossible to express a confused deputy vulnerability in a capability system?

(Asking for a colleague)

--------------
Alan Karp

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2kJG8HBW6ZO272jEb4kXHGDMP9s_w%3D47G5QNjw1dVU2Q%40mail.gmail.com.

[Alan Karp]

I'm interested in the counterexample, but I don't understand why either confinement or side channels are relevant to confused deputy.  

--------------
Alan Karp

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QMd%2Bqjy09AZtnJn%3DbHpcbH0h8L8erp0kcB2m5Az4qAR_Q%40mail.gmail.com.

[Jonathan S. Shapiro]

On Fri, Jul 24, 2026 at 7:43 PM Alan Karp <alan...@gmail.com> wrote:

I'm interested in the counterexample, but I don't understand why either confinement or side channels are relevant to confused deputy.

They aren't. But confinement is fairly important for a non-confused deputy. If a program cannot guard the control flow and data flow consequences of an in-bound message, it's not in a position to manage two (or more) distinct authority sets effectively.

I guess I'm not expressing this well. Maybe I'm just mixing up two unrelated things; it's been a pretty long day.

While confinement as default is essential for caller trust of discretion, I think that in some respects the more essential defensive mechanism in the KeyKOS family is the fact that a start key identifies a closure that receives a message, and the message received is associated with an unforgeable identifier (in KeyKOS the data byte, much later grew into the protected payload) that names it's application-level destination object.That's the connected chain that makes it possible for the service to know unambiguously what code is to be invoked.

Ah. The reason confinement is relevant is that, in practice, few objects are really confined. The start without the ability to write beyond their confinement boundary, but we tend to quickly hand them a bunch of "environment" capabilities that selectively 

[Matt Rice]

I assume you meant to finish with 'selectively break confinement', or similar.

This reminds me of a conversation William ML Leslie, and I had a while
back about the original confused deputy compiler example. In
particular if the compiler captures a log capability which can write
to a log file which the creator can presumably read,
The observation is that such a capability can not be shown to be
confined, if it contains a channel readable to its creator. I assumed
that it could have been using the `hole` mechanism of the keykos
factory to create a limited write channel perhaps as small as some
numeric type representing the cost of the transaction. I don't recall
Norm going into specifics of how the compiler example really worked on
keykos but it seems much like what you're describing here.

[Alan Karp]

The systems I'm dealing with are all on the open Internet, so confinement isn't a consideration.

--------------
Alan Karp

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QO9GP5ROx6tLqUnwr_wvcqnwvgqXEUeFUHW47qXGpE3cw%40mail.gmail.com.