Allow ACL doc discovery without acl:Control #248
Conversation
This is a spec change proposal. ### Practical Reason Most current implementations of Solid allow ACL doc discovery without acl:Control. For instance, NSS and CSS just add `.acl` and ESS adds `?ext=acl`. It would be a lot of work (including data migration on all existing servers) to change that. ### Simplicity Reason Using a predictable scheme makes the life of the server developer easier. Also, reporting the `Link` header in for instance OPTIONS makes it easier to discover if a server *supports* WAC at all, which is useful both to app developers and to end-users of apps. You can then see "ah, there is an ACL link but I don't have access", rather than being kept in the dark about it altogether. ### Reasons against it * If the ACL doc URL is predictable, there is a real risk that app developers skip the discovery and just guess it. However, now that different servers already use different schemes, I don't think many app developers will do this anymore. * If the ACL doc URL is predictable, it might give an attacker a leg up (help them overcome the first barrier). The could then for instance try to brute-force their way into the ACL doc. However, if they can brute-force their way into `acl:Control` then they would maybe also be able to use that technique to break the barrier to discovery.
|
There is no guarantee whatsoever that the URL is predictable. -1 for me |
How is that relevant? This is about whether the |
That is a good point, and good to leave that open. So the spec should say that whether or not discovery of the ACL doc URL requires |
There was a problem hiding this comment.
So the spec should say that whether or not discovery of the ACL doc URL requires
acl:Controlis up to the server.
It should not; the existing text is just fine. Discovery requires Control permissions.
The existence of another channel to discover doesn't change that.
|
As far as I can tell, the rationale to limit "discovery" to agents with Control is not well-documented beyond it being introduced in early PRs for auxiliary resources. There is no "[Source]" link to the requirement. I know the requirement was mentioned/repeated in discussions but underlying reasons seems to be left out. There is much material/chat to process, but if anyone can link me to the background, I'd love to review. As already mentioned, what's in the spec (re "discovery") is not based on existing server implementations. What that tells me is that while the decision to limit is done with good intentions (possibly intuitive or correct or preferred..), it wasn't based on observable practice. Again, this is one of the reasons why "Source" links for each spec requirement (at least in one of the drafts) is important/useful! "Open standards" based on open discussion and consensus. With receipts. Thanks for raising this issue/PR @michielbdejong @ylebre . This PR can at least serve as a (repeat) review for the behaviour.
True. Always possible if one implementation is designed against another implementation (as opposed to the specification). The Protocol prescribes the required behaviour for ACL discovery. If developers are willing to ignore the spec, obviously it doesn't prevent them from developing an application against a specific server, and they do that with all the risks and limitations associated to it. Doesn't matter what the specs at this point. Perhaps more of a concern is when attackers target a server implementation or even specific pods. Limiting the discovery of ACL to agents with Control keeps the attack surface small(er) - cuts it in half? When a server is under a DDoS attack targeting the ACLs, it may also need to temporarily block access to the resources linking to the ACLs, or possibly just omit the Link header, to avoid further disturbance. That would be an interruption to legitimate use of the server - even if small. Consider the cases where Read is assigned to a resource for (un)authenticated agents/clients.. and the ACL URL is observable. Having said that, servers generating ACL URIs based on a deterministic algorithm (eg.
I don't feel comfortable about allowing this sort of "Variability in Specs" ( #138 ) especially for access control. Prefer to have one reliable approach. Having Read access on a resource grants one to view a representation. Container representations include statements about contained resources irrespective of agent having any access to the contained resources. The question is whether the exposure of the ACL resource from the associated resource is similar or can be seen to fit in the same category. In any case, we can still introduce exceptions ie. require Control on resource in order to include Link. I'd be interested in reviewing more material before making any changes to the spec. The current requirement can be relaxed/removed at any time. Yes, in the meantime, some servers do not appear to conform on this requirement. So let's gather more data. That includes getting more feedback from developers about their current/future implementations. |
|
ACP doesn't use 'Control' and Access Control Resource include explicit policies for accessing the ACR itself. In that case discovery probably would depend on those policies granting (or not) Requesting Party access to the ACR. Maybe it would make sense to have mini spec just for Solid-WAC integration and separate one for Solid-ACP integration? |
|
WAC is a way of setting Protocol's default behaviour and taking security considerations into account. If required, an explicit policy for discovering ACL resources can also be done. |
|
I think the text is ok. |
This shouldn't be left up to implementation, regardless of direction.
Since I did that submission - the motivation behind it starts with principle of least privilege - which is specifically relevant here given the role of the acl in the security posture of the system. To @csarven's point - it minimizes the attack surface. This is a general best practice we should continue to employ where we can. I think that as part of the drafting process we need to look for reasonable opportunities to improve security posture, even if existing implementations may need to be adjusted to conform. This should be done judiciously, but this seemed like a reasonable case (and still does). |
|
As far as I can tell the removal of the text "discover" from the specification is appropriate and consistent with the Protocol. I'm in approval of the initial commit made to this PR ( 4639a5d ): RFC3986 https://tools.ietf.org/html/rfc3986#section-7 states:
Introducing a security consideration for servers using a deterministic algorithm to generate a URI string does not fundamentally address the perceived concern on discovering the name of access control resources. Even if servers were to omit the link relation, it is trivial to look up the algorithm generating the URI string, especially in the case of open-source servers, and so server implementations and pods using them can be targeted en masse. It is also worthwhile to consider scenarios where the access control source can be obtained in other ways eg. agent used to having Control access or having prior knowledge about the algorithm generating the string. (RFC 3986 blurb) The only rule that can universally address this is by requiring servers to follow a certain URI Template for access control URIs eg. "Servers MUST use a non-deterministic (unguessable) algorithm to generate the URI string when allocating it to access control resources." This adds unnecessary complexity to the system. Knowing an identifier != access. Similar to having Read access to a container and observing the containment statements does not entail having access to the contained resources. (RFC 3986 blurb) The Solid Protocol must remain neutral and flexible about this by not requiring how servers name their resources. (Please do not bring up slash semantics into this discussion!) Access control resources of WAC was never classified as "secret" - no documentation suggests this. Implementations simply followed this practice and at the very least did not deem them to be secret or a security threat. (RFC 3986 blurb) Again, where needed, explicit policies controlling the discoverability of access control resources through HTTP headers (or anywhere) can still be prescribed/achieved per mechanism. |
|
I agree
The specification should state what has to be, not what should not be, as that would be closing possibilities that are unknown. The same with tests. For example the proposal ACLs on ACLs for WAC would make tests that just check for |
| <p>To discover, read, create, or modify an ACL auxiliary resource, an <code>acl:agent</code> MUST have <code>acl:Control</code> privileges per the <a href="https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm">ACL inheritance algorithm</a> on the resource directly associated with it.</p> | ||
| <p>To read, create, or modify an ACL auxiliary resource, an <code>acl:agent</code> MUST have <code>acl:Control</code> privileges per the <a href="https://github.com/solid/web-access-control-spec#acl-inheritance-algorithm">ACL inheritance algorithm</a> on the resource directly associated with it.</p> | ||
|
|
||
| <p>Whether or not <code>acl:Control</code> is also required to *discover* an ACL auxiliary resource, is left up to the server implementer.</p> |
There was a problem hiding this comment.
| <p>Whether or not <code>acl:Control</code> is also required to *discover* an ACL auxiliary resource, is left up to the server implementer.</p> | |
| <p>Whether <code>acl:Control</code> is required to <em>discover</em> an ACL auxiliary resource, is left to the implementation.</p> |
|
I have added a detailed example on how ACLs on ACLs could allow protected resources to have public ACLs without leaking information. The example shows how Alice may find it useful to know that she has access to an What that shows is that acl discovery should be put in terms not of (There is in my view no problem either with ACLs being discoverable and yet not being readable, since we know logically that all resources have ACLs. Knowing the name of an ACL does not give any new information out. It may just be inconvenient as it suggests that the link can be followed, and so may result in another request with a 401) |
|
I opened up a complimentary PR that goes a little further than this one, taking into account use cases from the Authorization panel #250 |
|
Continued in #252 |
|
We can now consider this issue as resolved. A client needs (at most) |
I agree. Is that written out somewhere? It seems I have only seen text being removed. :-) |
This is a spec change proposal.
Practical Reason
Most current implementations of Solid allow ACL doc discovery without acl:Control.
For instance, NSS and CSS just add
.acland ESS adds?ext=acl.It would be a lot of work (including data migration on all existing servers) to change that.
Simplicity Reason
Using a predictable scheme makes the life of the server developer easier.
Also, reporting the
Linkheader in for instance OPTIONS makes it easierto discover if a server supports WAC at all, which is useful both to app
developers and to end-users of apps. You can then see "ah, there is an ACL
link but I don't have access", rather than being kept in the dark about it altogether.
Reasons against it
If the ACL doc URL is predictable, there is a real risk that app developers skip
the discovery and just guess it. However, now that different servers already
use different schemes, I don't think many app developers will do this anymore.
If the ACL doc URL is predictable, it might give an attacker a leg up (help them
overcome the first barrier). The could then for instance try to brute-force their
way into the ACL doc. However, if they can brute-force their way into
acl:Controlthen they would maybe also be able to use that technique to break the barrier to
discovery.