Confused deputies, small thought on ACLs

[Jonathan S. Shapiro]

This morning's random thoughts...

I made reference to confused deputies in a requirements document today, which caused me to re-read the Wikipedia page for the Confused Deputy Problem and also Amazon's description (which is quite good). We tend to describe the confused deputy problem by saying that the deputy is "more privileged," and Wikipedia seems to have picked that up. This is not correct; it is sufficient that the deputy wields authority not possessed by its client. That is: it is differently privileged, not more privileged. The Amazon description does a better job on this than the Wikipedia page.

One of the references then led me to Tyler's "ACLs Don't" paper, and the title provoked me to think about ACLs for a few moments. There are actually three problems:

1. ACLs are not ransferrable and therefore do not provide fine-grain control.
2. ACL entries are added and removed by the wrong party -- though this can also be done in capability systems that provide a "wrapper" object.
3. ACL systems are rarely designed to designate their source of authority at invocations.

It is possible to craft an ACL system in which users are represented by access tokens that are explicitly presented at invocations. In such a system, the confused deputy problem is solvable. An explicitly presented user token acts something like a "fat" capability in the confused deputy scenario. The key requirements to avoid the confused deputy are:

1. The source of authority must be designated
2. Authority is never composed under a union operation.

Composing authority under an intersection operation is perfectly okay. 

Thinking about this caused me to recognize once again that capability systems have a dual problem: capabilities do not convey information about agency. We know a capability was used, but we don't know how the wielder came to hold it. While we don't want to make access decisions based on the delegation path, it is sometimes critical to be able to know after the fact what the delegation path was. There are analogous examples in ACL systems: the interactive customer support person may be wielding my authority, but it's important to know later that I wasn't the originator of those operations if something goes wrong. In some capability systems this can be solved with a logging membrane, but in systems where traceability of this kind is required it probably wants to be baked in.

Mostly idle thoughts, though I wonder if the Wikipedia page shouldn't be re-touched?

Jonathan

[Charlie Landau]

On 12/10/21 10:07 AM, Jonathan S. Shapiro wrote:

While we don't want to make access decisions based on the delegation path, it is sometimes critical to be able to know after the fact what the delegation path was.

To prevent making decisions based on the delegation path, the ability to know what the delegation path is must require additional/different privilege/capability.

In some capability systems this can be solved

Yes I believe that.

in systems where traceability of this kind is required it probably wants to be baked in.

That's debatable. It goes counter to Norm's philosophy of keeping the kernel minimal to improve reliability.

Mostly idle thoughts, though I wonder if the Wikipedia page shouldn't be re-touched?

It should, and since it's a wiki, you can feel free to do it.

[Matt Rice]

On Fri, Dec 10, 2021 at 6:07 PM Jonathan S. Shapiro
<jonathan....@gmail.com> wrote:
>
> This morning's random thoughts...
>
> I made reference to confused deputies in a requirements document today, which caused me to re-read the Wikipedia page for the Confused Deputy Problem and also Amazon's description (which is quite good). We tend to describe the confused deputy problem by saying that the deputy is "more privileged," and Wikipedia seems to have picked that up. This is not correct; it is sufficient that the deputy wields authority not possessed by its client. That is: it is differently privileged, not more privileged. The Amazon description does a better job on this than the Wikipedia page.
>
> One of the references then led me to Tyler's "ACLs Don't" paper, and the title provoked me to think about ACLs for a few moments. There are actually three problems:
>
> ACLs are not ransferrable and therefore do not provide fine-grain control.
> ACL entries are added and removed by the wrong party -- though this can also be done in capability systems that provide a "wrapper" object.
> ACL systems are rarely designed to designate their source of authority at invocations.
>

I've probably mentioned it before, but another property which ACLs
have is completeness, as in there is a boolean response to every
possible access control query,
contrasted with a capability which may or may never actually yield any
result, a need for a boolean response before the question has been
asked has always struck me as some suspect.

> It is possible to craft an ACL system in which users are represented by access tokens that are explicitly presented at invocations. In such a system, the confused deputy problem is solvable. An explicitly presented user token acts something like a "fat" capability in the confused deputy scenario. The key requirements to avoid the confused deputy are:
>
> The source of authority must be designated
> Authority is never composed under a union operation.
>
> Composing authority under an intersection operation is perfectly okay.
>
> Thinking about this caused me to recognize once again that capability systems have a dual problem: capabilities do not convey information about agency. We know a capability was used, but we don't know how the wielder came to hold it. While we don't want to make access decisions based on the delegation path, it is sometimes critical to be able to know after the fact what the delegation path was. There are analogous examples in ACL systems: the interactive customer support person may be wielding my authority, but it's important to know later that I wasn't the originator of those operations if something goes wrong. In some capability systems this can be solved with a logging membrane, but in systems where traceability of this kind is required it probably wants to be baked in.
>
> Mostly idle thoughts, though I wonder if the Wikipedia page shouldn't be re-touched?
>
> Jonathan
>

> --
> 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/CAAP%3D3QNUSvs-DJm96%2BEBuBLsU%2BuDcGdn-PQzCXfAPTgjt36H0Q%40mail.gmail.com.

[Mark S. Miller]

Best explanation of Horton is https://www.youtube.com/watch?v=NAfjEnu6R2g&list=PLzDw4TTug5O0ywHrOz4VevVTYr6Kj_KtW

This explanation I think touches upon the issues Shap raises well.

Comments appreciated!

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

[Matt Rice]

Not really sure who to respond to on this one.

As it relates to "decisions based on delegation path", Shap and
Charlie discuss, but the underlying mechanisms of Horton as well...
In particular in Keykos the factory requestor's key, and the check
that a "factory" comes from an "official factory", can be viewed as a
coarse form of decision based on delegation path...
as well as the kernel objects being "Sensory".

The thing I note is that
http://www.erights.org/elib/capability/dist-confine.html brings
delegation path into the definition of sensory to some extent.
Much of the Horton work seems complementary to dist confinement not in
a reactive, but proactive fashion...

I.e. when we bridge 3 systems with distributed confinement across
trust boundaries as in the very beginning of your talk.
In particular the case where Alice trusts Carol's capabilities are
sensory, and Alice trusts Bob's capabilities are sensory, and vice
versa.
During the introduction of Carol to Bob we essentially run into the
same problem with Bob's & Carol's lack of knowledge of each other and
being subject to Alice's interpretation of sensory.
The same mechanisms used in Horton seem to allow Alice to convey to
Bob the boundaries by which her first and second hand knowledge of
"sensory" applies to the capabilities within a space.

an aside, the term sentries is used in the beginning which gets rolled
into "identity pathways" later, in this case sentries is presumably
better, as we are attesting to some kernel behavior
rather than a particular user's capabilities.

Not sure if these are useful thoughts, but they are thoughts...

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

[Alan Karp]

On Fri, Dec 10, 2021 at 10:07 AM Jonathan S. Shapiro <jonathan....@gmail.com> wrote:

Thinking about this caused me to recognize once again that capability systems have a dual problem: capabilities do not convey information about agency. We know a capability was used, but we don't know how the wielder came to hold it. While we don't want to make access decisions based on the delegation path, it is sometimes critical to be able to know after the fact what the delegation path was. There are analogous examples in ACL systems: the interactive customer support person may be wielding my authority, but it's important to know later that I wasn't the originator of those operations if something goes wrong. In some capability systems this can be solved with a logging membrane, but in systems where traceability of this kind is required it probably wants to be baked in.

Knowing the delegation chain makes sense if all parties are part of the same organization. In general though, knowing the identifiers of participants in the delegation chain is useful only to the direct delegator to that participant.  Say that Alice delegates to Bob who delegates to Carol.  Alice clearly had some knowledge of Bob in order to make the delegation, but she is likely to have no way of knowing who Carol is.  As far as Alice knows, Carol could even be a sock puppet of Bob.  

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