Is this a confused deputy?

10 views
Skip to first unread message

Alan Karp

unread,
Jun 11, 2025, 6:00:07 PMJun 11
to <friam@googlegroups.com>, cap-...@googlegroups.com
Alice has some files, each for a different subset of her data.  For simplicity, say that there is a file for each letter of the alphabet, and a word goes into a file if the word contains the corresponding letter.  Bob runs a service that tells Alice which files to update for a given word.  If he is malicious, Bob will specify a file not in that set, which Alice will overwrite using her permissions.

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

Mike Stay

unread,
Jun 11, 2025, 8:13:30 PMJun 11
to fr...@googlegroups.com, cap-...@googlegroups.com
Seems more like a type error to me.  Alice should expect a set of files of a type that depends on the given word.  Bob is providing the service on an open network where Bob is just sending bits, then Alice should either expect Bob's responses to contain a proof that they're a serialization of the right type or Alice should prove it to herself.

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z2D-mdscZ8H6%3DtjCrjW%3D0-DqyHKV_hkfR4Vmv89D5qw-Q%40mail.gmail.com.


--

John Carlson

unread,
Jun 11, 2025, 8:27:43 PMJun 11
to cap-...@googlegroups.com

Sounds like Bob’s messages need to be validated/verified by Alice.  If Alice is not able, because a service is unavailable, Bob will succeed.

John

--
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/CANpA1Z2D-mdscZ8H6%3DtjCrjW%3D0-DqyHKV_hkfR4Vmv89D5qw-Q%40mail.gmail.com.

Alan Karp

unread,
Jun 11, 2025, 8:30:42 PMJun 11
to cap-...@googlegroups.com
That sounds like an argument people make about Norm's version.  "The compiler should check which file the caller specifies."  In terms of types, there is no type difference among files in a conventional system.

--------------
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/CAKQgqTYsYan51J%2BpZBk-3Ty71Zcxw6j8AkM-WzmBUAg-wKF-KQ%40mail.gmail.com.

John Carlson

unread,
Jun 11, 2025, 8:38:16 PMJun 11
to cap-...@googlegroups.com
There’s also an aspect where Alice has a schema derived from an object model given by Bob, and a validator provided by Carol, which uses the schema.  Schema test files are provided by Bob as well.

This is a real scenario.  The recommendation is for Alice to build an API with validation, not necessarily a schema.

John 

Gernot Heiser

unread,
Jun 11, 2025, 8:40:47 PMJun 11
to cap-...@googlegroups.com, <friam@googlegroups.com>
On 12 Jun 2025, at 07:59, Alan Karp <alan...@gmail.com> wrote:
>
> Alice has some files, each for a different subset of her data. For simplicity, say that there is a file for each letter of the alphabet, and a word goes into a file if the word contains the corresponding letter. Bob runs a service that tells Alice which files to update for a given word. If he is malicious, Bob will specify a file not in that set, which Alice will overwrite using her permissions.

Bob is given all authority to Alice’s data, and is as such a trusted entity. It’s not a confused deputy, but a malicious trustee. Bob is essentially root.

Gernot

Raoul Duke

unread,
Jun 11, 2025, 9:02:36 PMJun 11
to cap-...@googlegroups.com
I feel like a point is that Alice asked Bob for instructions thus is two-way. Alice has the chance and responsibility to error/sanity/security check the instructions, ideally.

Whereas me sending my demon print job to the print daemon to overwrite /etc/password ha ha is one-way. That is a confused deputy. 

Alan Karp

unread,
Jun 11, 2025, 9:14:10 PMJun 11
to cap-...@googlegroups.com
Bob does not have permission to write the files, as he would if he was root.  He simply tells Alice which file to write.

--------------
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.

Alan Karp

unread,
Jun 11, 2025, 9:17:46 PMJun 11
to cap-...@googlegroups.com
On Wed, Jun 11, 2025 at 6:02 PM Raoul Duke <rao...@gmail.com> wrote:
I feel like a point is that Alice asked Bob for instructions thus is two-way. Alice has the chance and responsibility to error/sanity/security check the instructions, ideally.

Whereas me sending my demon print job to the print daemon to overwrite /etc/password ha ha is one-way. That is a confused deputy. 

Good point, but my example seems to capture the essence of the vulnerability; one party designates a file that the other one writes.

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


On Wed, Jun 11, 2025 at 6:02 PM Raoul Duke <rao...@gmail.com> wrote:
I feel like a point is that Alice asked Bob for instructions thus is two-way. Alice has the chance and responsibility to error/sanity/security check the instructions, ideally.

Whereas me sending my demon print job to the print daemon to overwrite /etc/password ha ha is one-way. That is a confused deputy. 

--
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.

John Carlson

unread,
Jun 11, 2025, 9:21:52 PMJun 11
to cap-...@googlegroups.com
Yes, Alice should test Bob’s service with sample files.  But then, Bob’s service may be updated, so periodic retesting should be done.

A problem with code artifacts is that Bob may refuse to run code that he generated to show the code is incorrect, so everything is “ok.”  Blame the messenger who reported the bug, “Not reproducible by anyone else.”  Alice is the only one actually running the code with output turned on.

Then, attempts to upstream fixes is blocked as well.

Blame the autistic for not socializing properly?

John 

On Wed, Jun 11, 2025 at 8:02 PM Raoul Duke <rao...@gmail.com> wrote:
I feel like a point is that Alice asked Bob for instructions thus is two-way. Alice has the chance and responsibility to error/sanity/security check the instructions, ideally.

Whereas me sending my demon print job to the print daemon to overwrite /etc/password ha ha is one-way. That is a confused deputy. 

--
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.

Charlie Landau

unread,
Jun 11, 2025, 10:28:09 PMJun 11
to cap-...@googlegroups.com
It seems that what Alice actually has is a set of files, which contain whatever Bob says should go there.
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/CAKQgqTYsYan51J%2BpZBk-3Ty71Zcxw6j8AkM-WzmBUAg-wKF-KQ%40mail.gmail.com.


--
Charlie Landau
he/him/his (Why Pronouns Matter)

Alan Karp

unread,
Jun 11, 2025, 11:44:33 PMJun 11
to cap-...@googlegroups.com
The solution is the same as Norm's, which is what led me to make the connection.  Alice gives Bob an ocap for each file containing the words.  Bob can mess with those files but no others.

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


David Nicol

unread,
Jun 12, 2025, 12:04:38 AMJun 12
to cap-...@googlegroups.com
On Wed, Jun 11, 2025 at 7:40 PM Gernot Heiser <gernot...@gmail.com> wrote:
 It’s not a confused deputy, but a malicious trustee.

Wow! its a kind of vulnerability that isn't confused deputy! Is there a comprehensive enumeration?

--
Nothing but net

Raoul Duke

unread,
Jun 12, 2025, 1:42:07 AMJun 12
to cap-...@googlegroups.com
i'm confused

i thought the original situation did not have Bob actively doing anything to alice's data,

so no ocap needs to be passed??

Alan Karp

unread,
Jun 12, 2025, 11:26:17 AMJun 12
to cap-...@googlegroups.com
In the original, Alice tells the compiler which file to write.  The analogy to my example is the compiler tells Alice which file to write.

--------------
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.

Raoul Duke

unread,
Jun 12, 2025, 1:03:25 PMJun 12
to cap-...@googlegroups.com
Feels like an important in fact essential distinction,no?

it can only be a deputy if it is not me. 

if it is me i have nobody to blame but myself. 

which is a different category of problem. 

Alan Karp

unread,
Jun 12, 2025, 1:17:20 PMJun 12
to cap-...@googlegroups.com
On Thu, Jun 12, 2025 at 10:03 AM Raoul Duke <rao...@gmail.com> wrote:
Feels like an important in fact essential distinction,no?

it can only be a deputy if it is not me. 

if it is me i have nobody to blame but myself. 

which is a different category of problem. 

That argument applies to Norm's original statement of the problem.  The compiler could check to see if the output was going to the log file.  

I'm trying to identify if there is something inherently different between the two cases.  The key characteristic is that one party designates a file that the other writes.  In Norm's case, it's Alice designating the output file that the compiler writes.  In my example, it's Bob designating the file that Alice writes.  In both cases, the vulnerability arises from separating designation from authorization.  In both cases, using capabilities avoids the vulnerability.

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


Raoul Duke

unread,
Jun 12, 2025, 1:22:57 PMJun 12
to cap-...@googlegroups.com
Ah, yes, right - ocap does sound like a way to do it. 

(but it is not in my mind confused deputy. Only would be if Bob were directly writing to files which is not how it was originally stated iiuc.)


Alan Karp

unread,
Jun 12, 2025, 1:43:46 PMJun 12
to cap-...@googlegroups.com
On Thu, Jun 12, 2025 at 10:22 AM Raoul Duke <rao...@gmail.com> wrote:
Ah, yes, right - ocap does sound like a way to do it. 

(but it is not in my mind confused deputy. Only would be if Bob were directly writing to files which is not how it was originally stated iiuc.)

In the original, Alice is naming the file that Bob writes.  In my example, Bob is naming the file that Alice writes.  The only difference I see is that in the classic version, Alice invokes Bob and induces him to write one of his files.  In my example, Alice invokes Bob who induces Alice to write one of her files.  Is this difference significant? 

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


On Thu, Jun 12, 2025 at 10:22 AM Raoul Duke <rao...@gmail.com> wrote:
Ah, yes, right - ocap does sound like a way to do it. 

(but it is not in my mind confused deputy. Only would be if Bob were directly writing to files which is not how it was originally stated iiuc.)


--
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.

Raoul Duke

unread,
Jun 12, 2025, 1:48:38 PMJun 12
to cap-...@googlegroups.com
to my simple mind it is a key difference as i keep saying :-)

Matt Rice

unread,
Jun 12, 2025, 1:56:50 PMJun 12
to cap-...@googlegroups.com
On Thu, Jun 12, 2025 at 5:43 PM Alan Karp <alan...@gmail.com> wrote:
>
> On Thu, Jun 12, 2025 at 10:22 AM Raoul Duke <rao...@gmail.com> wrote:
>>
>> Ah, yes, right - ocap does sound like a way to do it.
>>
>> (but it is not in my mind confused deputy. Only would be if Bob were directly writing to files which is not how it was originally stated iiuc.)
>>
> In the original, Alice is naming the file that Bob writes. In my example, Bob is naming the file that Alice writes. The only difference I see is that in the classic version, Alice invokes Bob and induces him to write one of his files. In my example, Alice invokes Bob who induces Alice to write one of her files. Is this difference significant?
>

seems to me like it's pretty much the dual or co-confused-deputy...
where the direction of the arrow is reversed

> --------------
> Alan Karp
>
>
> On Thu, Jun 12, 2025 at 10:22 AM Raoul Duke <rao...@gmail.com> wrote:
>>
>> Ah, yes, right - ocap does sound like a way to do it.
>>
>> (but it is not in my mind confused deputy. Only would be if Bob were directly writing to files which is not how it was originally stated iiuc.)
>>
>>
>> --
>> 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/CAJ7XQb5JP-%2BZx_zmgPJxX_UdFYoLcjau2EkVNAg0-m11rB_hgQ%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/CANpA1Z3RC_EnUtDybBktZwUV08JV4Bdi%2BbtY3%3Dax%2BYefPriWOQ%40mail.gmail.com.

Alan Karp

unread,
Jun 12, 2025, 2:02:25 PMJun 12
to cap-...@googlegroups.com
Does that make it a simpler example to explain the problem?  Several people I have talked to find Norm's example unconvincing.

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


Raoul Duke

unread,
Jun 12, 2025, 2:04:00 PMJun 12
to cap-...@googlegroups.com
i think it changes the problem and is no longer C.D. 

dual is not equality. 

Alan Karp

unread,
Jun 12, 2025, 2:08:29 PMJun 12
to cap-...@googlegroups.com
Fair enough.  Is it a good way to explain the problem of separating designation from authorization?

My example is simpler in a couple of ways.  Norm's example uses 2 parameters while mine only uses one.  Also, when explaining Norm's example, I often get asked how the compiler service gets permission to read Alice's input file and write her output file.  That question doesn't arise in my version.

--------------
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.

Raoul Duke

unread,
Jun 12, 2025, 2:13:31 PMJun 12
to cap-...@googlegroups.com
Yes to me it does make sense as a way to use ocaps.  Especially since it can start to be a universal approach. 

Mike Stay

unread,
Jun 12, 2025, 2:42:26 PMJun 12
to cap-...@googlegroups.com
Your Alice is analogous to Norm's compiler and your Bob to Norm's
user. In both cases, Alice wants some invariant to hold (for Norm's
case, that the log file contains a log; for your case, that every word
in the file contains the distinguished letter), and Bob is providing
designating strings as input. Alice could check the strings to make
sure the invariant is upheld (as I suggested with the dependent type),
but remembering to do that for every invariant is error-prone. In
both cases, Alice is Bob's deputy, and Alice gets confused into
violating her invariant.

In Norm's case, ocaps solve the problem because Bob doesn't have an
ocap for writing to Alice's log file. In your case, simply giving Bob
an ocap to write to the files prevents him from getting Alice to write
to files other than the ones holding the word lists, but otherwise
doesn't prevent violating the invariants. The ocaps given to Bob need
to both designate the file *and* check the invariant. If Alice
forgets to check the invariant when issuing the ocap, using ocaps
won't help in your case.
> To view this discussion visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z1RyFyg48s7vzVjUmZYNhEP92i5aU0Wo4d_HQXUyaPCcg%40mail.gmail.com.

John Carlson

unread,
Jun 12, 2025, 2:51:40 PMJun 12
to cap-...@googlegroups.com
Perhaps one can get very concrete.  Alice creates two classes,  Class1.java and Class1$Class2.java

Class1.java looks like:

public Class1 {
class Class2  {}
}

Class1$Class2.java looks like

public Class1$Class2 {
}

What does the compiler create in

Class1$Class2.class?

John



Raoul Duke

unread,
Jun 12, 2025, 2:52:59 PMJun 12
to cap-...@googlegroups.com
Agreed iiuc your point that there are 2 things to validate: 

a) which files can be accessed

b) the algorithm which makes use thereof

i assume (b) is way too out in left field otherwise we would never write bugs, and things like ocaps are only about (a) reasonably. 

which is why even fine grained security controls like ocaps do not solve the actual usability problem for Joe Grandma User (or Me Programmer Nerd) entirely. 


Alan Karp

unread,
Jun 12, 2025, 4:40:25 PMJun 12
to cap-...@googlegroups.com
The issue is not whether Bob produces correct results; it's whether Bob can induce Alice to write to a file she doesn't want written.  Without ocaps, Bob sends Alice a string naming the file to be written.  With ocaps Alice gives Bob an ocap for each file she wants him to designate.  If I add the condition that Bob is on a different machine, then Bob sends back to Alice the ocap for the file she should write, which she then uses.

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


Alan Karp

unread,
Jun 12, 2025, 4:43:48 PMJun 12
to cap-...@googlegroups.com
I don't understand your example.  Maybe it's just that I haven't used Java since 1999!

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


John Carlson

unread,
Jun 12, 2025, 4:49:28 PMJun 12
to cap-...@googlegroups.com
Does it make a difference which system the file is on?   What if Bob starts sending arbitrary ocaps?  Does alice need to compare ocaps?

John

John Carlson

unread,
Jun 12, 2025, 4:58:58 PMJun 12
to cap-...@googlegroups.com
In Java, if you have a subclass, say Class2 of superclass Class1, then as far as I know, it gets compiled to Class1$Class2.class, colliding with the other class, Class1$Class2, from the other java file.  I haven’t personally tried this.

Not that anyone would do this, typically a .java file name with $ might cause problems in Linux, by variable substitution of variables with $ in the file name in bash.

I’m just saying this might be possible, but unlikely to occur in standard practice.

John

Alan Karp

unread,
Jun 12, 2025, 5:08:33 PMJun 12
to cap-...@googlegroups.com
On Thu, Jun 12, 2025 at 1:49 PM John Carlson <yott...@gmail.com> wrote:
Does it make a difference which system the file is on?   What if Bob starts sending arbitrary ocaps?  Does alice need to compare ocaps?

Bob's possession of an ocap signals that he can write the file.  In that case, he has no need to trick Alice into writing it.  The only exception would be if Alice is writing something Bob should not know. 

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


David Nicol

unread,
Jun 12, 2025, 5:13:21 PMJun 12
to cap-...@googlegroups.com

I liked "malicious trustee" as an alternative to CD and asked for a full enumeration. Nobody responded; I'm going to expand.

It seems like everything Capability Security tries to mitigate gets reduced to a CD problem as a matter of principle, which is great. Simplicity is an essential component of reliability and so on.

"the problem of separating designation from authorization" only makes sense after definition of the long words.

In normal day-to-day life, designation strongly implies authorization. 

Example: when I used to deliver pizza, one classy hotel had a policy that I was to enter their building via the loading dock rather than the front entrance, which involved walking through the kitchen on the way to the elevators. The designation into "waiter" status authorized limited access to employees-only zones of the hotel even though I was not an employee of the hotel. 

One time, there was heightened security at the hotel (which had nothing to do with my customer) and I was stopped and interviewed by guards, who quickly determined I was legit, which I was.

"Assassin enters hotel disguised as liveried food service staff" happens enough in movies that it probably has its own page at TV Tropes.

To deconstruct "malicious trustee" into its components and identify which part of the system is the deputy and at what point do they become confused seems like a worthwhile exercise.

I offer "pizza poisoning" as an idiom alternative to computer files for the purpose of discussing the issues. "CD" evokes images of escaping from jail in Westerns; there's a big cognitive dissonance involved in switching back and forth between how The Kid (arrested yesterday for public disturbance) manages to switch places with Clem (formally tasked with monitoring The Kid, not the sharpest buck-knife in the stump) and how Mallory manages to fool Bob into having Alice install Mallory's rootkit without either Alice or Bob knowing about it.

"Confused Deputy" implies Mallory: somebody is actively doing the confusing. For negative outcomes attributable to Genuine Stupidity (opposed to Artificial Intelligence, I've been trying to work that phrase in whereever I can, of late) we can pretend Mallory is a god of chaos, or poor design, or something -- because Mallory is required for reduction of all design weaknesses to Confused Deputy. Mallory is who causes the deputy, via exploitation of the weakness, to become confused.

So to deconstruct "malicious trustee" into a "confused deputy" problem, that's what I've set out to do here, first we need a "malicious trustee" example. Let's say Martin Blank has gotten himself employed by Dominoes in order to poison his target's pizza. He's a trustee, able to walk right through enhanced hotel security, except -- and nobody except his real employers and he know this -- he's malicious in that he has been waiting for his chance to poison the pizza, which he did at some point between the store and the hotel. Blank gets to claim another successful assassination on his impressive assassin's resume (this is Martin Blank we're talking about here! Not no John Wick walking tornado.)

From victim's security's point of view, Dominoes is the deputy and Dominoes was confused into hiring Blank. Dominoes is not malicious. For future protective details, Tony's Security is going to restrict their clients to ordering from vetted and trusted known-secure pizzarias instead of chains during active protection.

In general, "malicious trustee" problems resolve into CD problems in the trust predicate. Tony's trust predicate was flawed in that Tony trusted Dominoes to have a secure hiring practice which they did not, and "the hit" succeeded.

I'm not at all certain how to map "assassination via poison pizza" back to this discussion about who holds the open file descriptor and to which file, but I think (and I expect you will agree) it's a lot easier to think about.

I'm also not at all certain that I understand the difference between "designation" and "authorization" and suggest mapping it to non-technical scenarios for clarity.

Thoughts?










On Thu, Jun 12, 2025 at 1:02 PM Alan Karp <alan...@gmail.com> wrote:
Does that make it a simpler example to explain the problem?  Several people I have talked to find Norm's example unconvincing.

--
Nothing but net

Mike Stay

unread,
Jun 12, 2025, 5:55:36 PMJun 12
to cap-...@googlegroups.com
On Thu, Jun 12, 2025 at 2:40 PM Alan Karp <alan...@gmail.com> wrote:
>
> The issue is not whether Bob produces correct results; it's whether Bob can induce Alice to write to a file she doesn't want written. Without ocaps, Bob sends Alice a string naming the file to be written. With ocaps Alice gives Bob an ocap for each file she wants him to designate. If I add the condition that Bob is on a different machine, then Bob sends back to Alice the ocap for the file she should write, which she then uses.

Sorry, I lost sight of the exploit you gave in your first email. If
your only concern is that Alice might write to the wrong file, then
yes, write ocaps solve that problem.

Either way, I agree that it's a confused deputy problem.

Alan Karp

unread,
Jun 12, 2025, 6:27:53 PMJun 12
to cap-...@googlegroups.com
This sounds more like Mike Stay's misinterpretation of my question.  He was concerned that Bob might return incorrect results (poisoned pizza), while I was worried that Bob might get Alice to give the (unpoisoned) pizza to her grandmother who has digestive problems by telling Alice the wrong room number.

--------------
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.

David Nicol

unread,
Jun 13, 2025, 6:11:20 AMJun 13
to cap-...@googlegroups.com
On Thu, Jun 12, 2025 at 5:27 PM Alan Karp <alan...@gmail.com> wrote:
This sounds more like Mike Stay's misinterpretation of my question.  He was concerned that Bob might return incorrect results (poisoned pizza), while I was worried that Bob might get Alice to give the (unpoisoned) pizza to her grandmother who has digestive problems by telling Alice the wrong room number.

Does acting based on received information make you a deputy of the provider of the information? This conversation seems like it could easily slippery-slope into scenarios of trustless paralysis.

Alice has to ask Bob to find out her own room number?

Is Alice's lactose-intolerant nana an assassin? Is Sysyphus happy?

 

--
Nothing but net

Alan Karp

unread,
Jun 13, 2025, 11:18:17 AMJun 13
to cap-...@googlegroups.com
On Fri, Jun 13, 2025 at 3:11 AM David Nicol <david...@gmail.com> wrote:


On Thu, Jun 12, 2025 at 5:27 PM Alan Karp <alan...@gmail.com> wrote:
This sounds more like Mike Stay's misinterpretation of my question.  He was concerned that Bob might return incorrect results (poisoned pizza), while I was worried that Bob might get Alice to give the (unpoisoned) pizza to her grandmother who has digestive problems by telling Alice the wrong room number.

Does acting based on received information make you a deputy of the provider of the information? This conversation seems like it could easily slippery-slope into scenarios of trustless paralysis.

I'm trying to separate concerns specific to the application, such as the result of some computation, from access control concerns. 

--------------
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.

David Nicol

unread,
Jun 13, 2025, 2:35:33 PMJun 13
to cap-...@googlegroups.com
On Fri, Jun 13, 2025 at 10:18 AM Alan Karp <alan...@gmail.com> wrote:
On Fri, Jun 13, 2025 at 3:11 AM David Nicol <david...@gmail.com> wrote:
On Thu, Jun 12, 2025 at 5:27 PM Alan Karp <alan...@gmail.com> wrote:
This sounds more like Mike Stay's misinterpretation of my question.  He was concerned that Bob might return incorrect results (poisoned pizza), while I was worried that Bob might get Alice to give the (unpoisoned) pizza to her grandmother who has digestive problems by telling Alice the wrong room number.

Does acting based on received information make you a deputy of the provider of the information? This conversation seems like it could easily slippery-slope into scenarios of trustless paralysis.

I'm trying to separate concerns specific to the application, such as the result of some computation, from access control concerns. 

So not all bugs are access control bugs. In the pizza model, there is what kind of pizza, and where to deliver the pizza to. To successfully deliver food, the system gets both of those right. Innocent mistakes do happen, causing failure. Innocent mistakes are bugs, they aren't access control problems, outside of, say, an organization that is so obsessed with quality that they go beyond what would seem reasonable to ensure they always succeed regarding these two dimensions (which food, where to take it). I feel like it's okay to share that I've always felt kind of validated by the existence of DoorDash and such because when I was delivering pizza and it was slow I would often imagine some kind of clearinghouse and at-large mobile food delivery agents, instead of each driver being associated with only one restaurant. 

We need a name for "problem that is not a confused deputy problem reasonably mitigable by use of capability-based security" and I think "normal bug" -- two words, to match "confused deputy" -- should do.

The original question, "is this a confused deputy" can now be clarified, by stating the implied part, to "is this a confused deputy or a normal bug" 

Could even narrow it to "confused trustee" but that might wind up more confusing, and merely push the question to a different pair of special terms without really identifying the distinction clearly, so let's not.

Maybe the line should be between "malicious confusion" and "innocent confusion." This would accept "confusion can, does, and will happen" as the unfortunate fact it is; this would allow clarity in determining an organization's acceptable level of confusion; allow adjusting the ALOC (acceptable level of confusion) metric as continuous improvement happens.

The last Dominoes I worked at took their support for food allergic customers very seriously, and had special crusts for celiac customers. When there was a gluten-free order, to be safe the manager would make it himself rather than trusting an inexperienced cook to get the various small adjustments to the normal procedure right. The manager practiced heightened security at such times by taking the confusable deputy out of the control path. The ALOC did not include risking the possibility of innocently poisoning a customer by sending them a normal crust.

Communication errors -- what kind of food, where to deliver it to can both be mistranscribed -- or miscalculated, possibly based on a miscommunication -- might not be mitigable with access control paradigms. Redundancy can help but errors will still sneak through. Say a dyslexic order-taker writes down the wrong address but then repeats back to the customer, on the phone, the address the customer said, which is not what Dillon Dyslexic wrote down. Nobody is being malicious but the manager would do well to take Dillon off the phones ASAP. Dillon is incapable, in the purest general sense, of taking phone orders at a Dominoes. Assigning this task to Dillon would be an error and shouldn't happen twice.

In both cases -- Due to something Bob did, Alice gets the wrong pizza, or due to something Bob did, Alice's pizza goes to the wrong room -- Bob does something wrong.

"is this a confused deputy" has to do with determining why Bob did the wrong thing, not the nature of the wrong thing done.


maybe we should start saying "exploitable weakness" instead of "confused deputy" towards reducing the risk of snowing our clients into agreeing with all of our recommendations because they have no idea what we're talking about.




--

Nothing but net

John Carlson

unread,
Jun 13, 2025, 3:56:39 PMJun 13
to cap-...@googlegroups.com
I call it, “weak validation.”   Ocaps help with validation, but if you give the wrong address to the pizza deliverer, the pizza deliverer also has a phone number to call, say, in case the address got mistranscribed.

John

--
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.

Alan Karp

unread,
Jun 13, 2025, 4:35:51 PMJun 13
to cap-...@googlegroups.com
I agree with a lot of what you say, but not everything.  The main difference is "confused deputy" is short for "confused deputy vulnerability."  The word "vulnerability" implies there is a weakness that can be exploited.  While something bad can happen due to a bug, I think we should focus on intentional exploitation of a vulnerability.  

I think "bug" is too broad a term.  Returning 4 for 1 + 2 is a bug.  Telling the compiler its output should go to some file you didn't intend is a bug.  Intentionally telling the compiler to overwrite the log file is an exploit.  "Malicious confusion" captures this case, but is "rights confusion" better?  That's what's happening when the compiler uses its permission to write its output to the log file.  It is confused about who's rights to use when writing its output.

I would say your Domino's Pizza stories fall under the 1 + 2 = 4 category, where there is no malicious intent.  Purposely telling dyslexic order takers an address that is chosen to confuse them is maliciously exploiting  (malicious confusion) a known vulnerability, although it is not the kind of confused deputy vulnerability I've been talking about (rights confusion).

--------------
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.

Jonathan S. Shapiro

unread,
Aug 23, 2025, 6:12:28 PMAug 23
to cap-...@googlegroups.com
Charlie Landau: Sent an email to your personal address with no reply. Check spam?

On Wed, Jun 11, 2025 at 7:28 PM Charlie Landau <cha...@charlielandau.com> wrote:
It seems that what Alice actually has is a set of files, which contain whatever Bob says should go there.

On 6/11/25 5:13 PM, Mike Stay wrote:
Seems more like a type error to me.  Alice should expect a set of files of a type that depends on the given word.  Bob is providing the service on an open network where Bob is just sending bits, then Alice should either expect Bob's responses to contain a proof that they're a serialization of the right type or Alice should prove it to herself.

On Wed, Jun 11, 2025 at 4:00 PM Alan Karp <alan...@gmail.com> wrote:
Alice has some files, each for a different subset of her data.  For simplicity, say that there is a file for each letter of the alphabet, and a word goes into a file if the word contains the corresponding letter.  Bob runs a service that tells Alice which files to update for a given word.  If he is malicious, Bob will specify a file not in that set, which Alice will overwrite using her permissions.

--------------
Alan Karp
--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/friam/CANpA1Z2D-mdscZ8H6%3DtjCrjW%3D0-DqyHKV_hkfR4Vmv89D5qw-Q%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.

--
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.
Reply all
Reply to author
Forward
0 new messages