Designating the resource in an invocation

[Alan Karp]

UCAN is a certificate-based capability system.  The UCAN invocation spec shows the invocation (where I've removed fields unnecessary for this discussion) as

type Invocation struct {
  run     &Task
  auth    &Authorization
  prf     [&UCAN]
}

(I'm not clear on the difference between auth and prf.)  Task is

type Task struct {
  on    URI
  call  Ability
  input {String : Any}
}

Here "call" is the method denoted as Ability for reasons I don't understand.  The "on" field in Task designates the resource; the "auth" (or "prf") field in the Invocation is the capability.  It is this separation of designation from authorization that concerns me.  

The use cases they show only involve a single resource, so the examples hide any potential problems of applying one authorization to another designation. 

Now to my question.  What can go wrong if the task involves multiple resources?

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

[Matt Rice]

On Mon, Jul 10, 2023 at 8:44 PM Alan Karp <alan...@gmail.com> wrote:
>
> It is this separation of designation from authorization that concerns me.

It looks to me this is not the typical separation of designation from
authorization we normally observe, in that the authorization field
contains a proof of authorization for multiple tasks, and the task
being designated in an invocation must be contained within the
authorization. So, while there is some separation via task it is still
in essence "linked" to the authorization. I haven't thought about
this for nearly enough time to begin to formulate what could go awry,
but that Invocations and authorizations both designate a task seems
more promising to me than the typical cases of separation of
designation from authority... Further, authorization actually
authorizing multiple tasks has a somewhat passing similarity to the
way a "normal" capability system can attenuate multiple facets of a
capability, so I then ask myself in a "normal" capability system
whether/how attenuation of multiple resources can go awry?

> Now to my question. What can go wrong if the task involves multiple resources?

It certainly isn't obvious to me... besides it seems to be very easy
for issuers to over-authorize treating the authorization field as an
ACL rather than a capability.

[Matt Rice]

Apologies, just hope to clarify my stance on the above, since it
perhaps isn't very clear

It seems like the UCAN text author considers it a capability system,
or at least to be isomorphic to one...
I can somewhat see the argument for that, if you consider that the
task designation in the invocation cannot contain anything that is not
in the authorization.
The difference being that the authorization does not *uniquely*
designate but potentially designates multiple things.

*if* the argument that it is isomorphic to a normal capability system
stands, it behooves us to try and replicate the issues in a normal
capability system.
This may likely be similar to the sorts of "Introduce confused deputy
by making a capability to a hashmap<filename, file> and delegating
capabilities by name" problems.
It seems likely to me that one could achieve such contortions on a
"normal" capability system for example "Attenuate a hashmap<filename,
file> capability attenuating it to a file contained within it".
I'm fairly certain I could do such a thing in seL4 by invoking a
message given a filename to a hashmap, replying with a badged endpoint
to a specific file in the hashmap. Sounds terrible, but possible.

Another question is whether the "Task" url itself can likely be used
as a source of confused deputies in the same way that filenames are at
the application level.

Anyhow the impression I get is that it seems plausible we can
replicate these issues within a "normal" capability system, but the
contortions required to achieve the same effect should entail much
more effort than just doing the right thing.
while on a "normal" cap systems tend to promote making the
right/secure way to do things the easy/obvious way. I don't get this
same impression of an aversion to misuse from UCAN.

[Alan Karp]

Sorry for the delay in replying.  I had to find the time to grok what you were saying.

Yes, it's possible to confuse a deputy with capabilities.  Christine Weber demonstrated one with sealed boxes.  The error is picking whatever unsealer you have rather than one specific to the box.

My concern with the UCAN approach is more basic.  For example, the spec never says that the URI must match the resource designation in the Authorization.  That wouldn't be a problem except that they allow wildcard capabilities.  I've argued that those certificates are fine for delegation but must not be accepted in an invocation, something else omitted from the spec.

Then there's the problem of multiple arguments.  I don't believe there's a problem if there's a 1-1 mapping between arguments and authorization certificates, but what if the same resource is designated for multiple arguments?  These more complex patterns aren't covered by the UCAN use cases or the invocation spec.

My argument is that the spec should simply use the authorization certificate to designate the resource instead of a URL.  I believe that will remove any ambiguity.

--------------
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 on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFqbjsTwYU9hS7Dtr0WNML%2BX6RzL1ucXTS1h48tzC%2Bn2Cg%40mail.gmail.com.

[Matt Rice]

On Fri, Jul 14, 2023 at 10:25 PM Alan Karp <alan...@gmail.com> wrote:
>
> Sorry for the delay in replying. I had to find the time to grok what you were saying.
>
> Yes, it's possible to confuse a deputy with capabilities. Christine Weber demonstrated one with sealed boxes. The error is picking whatever unsealer you have rather than one specific to the box.
>
> My concern with the UCAN approach is more basic. For example, the spec never says that the URI must match the resource designation in the Authorization. That wouldn't be a problem except that they allow wildcard capabilities. I've argued that those certificates are fine for delegation but must not be accepted in an invocation, something else omitted from the spec.
>
> Then there's the problem of multiple arguments. I don't believe there's a problem if there's a 1-1 mapping between arguments and authorization certificates, but what if the same resource is designated for multiple arguments? These more complex patterns aren't covered by the UCAN use cases or the invocation spec.
>

Ouch, only looking at those invocation docs, I wasn't aware of
wildcard capabilities... I was assuming a 1-1 mapping as above, and I
agree that it makes all problems worse...
I still really don't like there being a 1:many mapping between
capability and authorization... even with a 1:1 mapping between
invocation target and authorization certificates.

There are a few things which still bother me even though without wildcards,
in a unforgeable capability something like: `Cap(unique_addr,
rights)`... the value `(unqiue_addr, Cap(unique_addr, rights))` it is
possible that a capability can be "no more powerful" than the former.
This is not the case here where we have `UCan-cap([unique_addrs,
...])`, but which can now be invoked if you have `(unique_addr,
UCan-cap([unique_addrs, ...]) where unique_addr exists in
unique_addrs` becomes invokable....

The entire fact that a capability can now present multiple
authorizations makes me worry/wonder if it doesn't expand the number
of individuals who need to be concerned about rights amplification.
I'm not certain what that would actually look like but it seems like
it could perhaps be an issue if there are multiple sources of
authorization in the capability.
anyhow this all seems far too fancy for simple me, but such issues are
probably par for the course with distributed systems. Either way i
feel like "stick all the authorizations in a bucket", leaves
ample opportunity to ignore rights amplification issues...

> My argument is that the spec should simply use the authorization certificate to designate the resource instead of a URL. I believe that will remove any ambiguity.

certainly no love for URLs which never seem any less problematic than
file names...

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

[Alan Karp]

On Fri, Jul 14, 2023 at 4:46 PM Matt Rice <rat...@gmail.com> wrote:

Ouch, only looking at those invocation docs, I wasn't aware of
wildcard capabilities... I was assuming a 1-1 mapping as above, and I
agree that it makes all problems worse...
I still really don't like there being a 1:many mapping between
capability and authorization... even with a 1:1 mapping between
invocation target and authorization certificates.

There is good reason to use wildcard delegation certificates.  It allows you to give me permission to all objects in a set, even objects added after you made the delegation.  However, I contend that certificate is not a capability because it does not designate a specific object.  I have recommended that the Authorization in a request MUST designate a specific resource.  I didn't get any pushback at the meeting, but I don't see that in the spec, either.

There are a few things which still bother me even though without wildcards,
in a unforgeable capability something like: `Cap(unique_addr,
rights)`... the value `(unqiue_addr, Cap(unique_addr, rights))` it is
possible that a capability can be "no more powerful" than the former.
This is not the case here where we have `UCan-cap([unique_addrs,
...])`, but which can now be invoked if you have `(unique_addr,
UCan-cap([unique_addrs, ...]) where unique_addr exists in
unique_addrs` becomes invokable....

That's an interesting point.  How do you designate a replicated object?  Does it have a single designation for all instances or a different designation for each?  Since you know where you're sending the message, I argue that you MUST use a certificate with a specific address in the invocation. 

The entire fact that a capability can now present multiple
authorizations makes me worry/wonder if it doesn't expand the number
of individuals who need to be concerned about rights amplification.
I'm not certain what that would actually look like but it seems like
it could perhaps be an issue if there are multiple sources of
authorization in the capability.
anyhow this all seems far too fancy for simple me, but such issues are
probably par for the course with distributed systems.  Either way i
feel like "stick all the authorizations in a bucket", leaves
ample opportunity to ignore rights amplification issues...

I agree. 

> My argument is that the spec should simply use the authorization certificate to designate the resource instead of a URL.  I believe that will remove any ambiguity.

certainly no love for URLs which never seem any less problematic than
file names...

The designation in a capability certificate may be a URI. 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFrHm_BkWckfgS-fQV86_hEaj8XN%3DfBWkQCC8Mr%3DWcz4BA%40mail.gmail.com.