This paper explains how toavoid certain unintended information flows betweenapps connected to the same Solid pod. We draw attention to threats faced sifecurity policies for Solid pods omit the identities of clients, resulting in confidential information intended for onaepp leaking to other apps. We also explain good practiceusage of ACP for avoiding such insecure configurations and draw parallels with the famousClark-Wilson policy model for enterprise security. We propose that trusted apps enforcing security policy models should be developed so that pod owners need not be policy experts to operate secure pods.
1. Introduction resource is requested. Beyond Solid, WAC is used by the W3C to specify access control for some of their own sites. On the other hand, ACP was introduced more recently toset more specific permissions in the Solid project thanWAC. In particular, ACP can setthe client (the Solid app) and issuer (identity provider).
This work explains pitfalls relatedto designing security policies using WAC and ACP.
We, (
1 @prefix acl: <http://www.w3.org/ns/auth/acl#> . 2 3 <#exampleOfWAC> 4 a acl:Authorisation; 5 acl:agent <https://solidweb.me/Ellie-s-Pod/profile/card#me>; 6 acl:default <https://solidweb.me/Ellie-s-Pod/Resource1/>; 7 acl:mode acl:Read, acl:Write.
In contrast, ACP provides more contextinformation, enabling the precise specification of agents through acp:agent, apps via acp:client, and Identity Providers (IDPs)using acp:issuer, depicted in Figure 2. The rest of the paper explains the security implications of these features for Solid. app1. A single trusted issuer is also named. 2.2. Clark-Wilson in ACP The Clark-Wilson model and acp:client in ACP have the common feature that the access to information via specified clients—the apps accessing resources within a Pod—can be restricted. Within the Clark-Wilson model, a fundamental component sometimes called the process (or Transformation Procedure c.f. Clark & Wilson) acts as an intermediary between the users and the resources, as do apps in the Solid framework.
In Clark-Wilson access is governed by “permissions” that specify the combinations of agent, client and resource for which access is permitted. Thus, in ensuring that only authorised clients are granted access, acp:client is aligned with the Clark-Wilson security policy model.
Illustrated in Fig. 3 is a conceptual representation of an example scenario for aSolid Pod, describing access control mechanisms available to Pod Owners. This framework empowers Pod Owners to meticulously tailor access privileges, allocating permissions to specific resources through designated applications. Furthermore, Pod Owners can permit more limited access to other agents, thereby enabling controlled interactionwith designated resources through authorised applications. In Fig. 3 a Pod Owner limits access to a resource resource1 when app1 is used and likewise for resource2 and app2. In addition, they have granted more restrictedaccess to an external agentto access resource2 only through app2.
The ACP policy governing resource1 in Fig. 3 was already provided in Fig. 2. That ACP policy can be extended with the policy ingoverning resource2 provided in Fig. 4. This ACP policy governs how two agents can access a resource referred to as resource2 in Fig. 3, as described above. This is a realistic scenario since it may be the case that the owner wishes to share more widely information in app2 while having the reassurance that information in resources accessed from app1 does not flow to app2.
1 <#exampleOfACP_2> 2 a acp:AccessControlResource; 3 acp:resource <https://solidweb.me/Ellie-s-Pod/Resource2/>; 4 acp:accessControl <#ownerAccess2>, <#externalAgent>; 5 acp:memberAccessControl <#ownerAccess2>, <#externalAgent>. 6 7 <#ownerAccess2> 8 a acp:AccessControl; 9 acp:apply [ 10 a acp:Policy; 11 acp:allow acl:Read, acl:Write; 12 acp:allOf [ 13 a acp:Matcher; 14 acp:client <https://solidweb.me/ClientPod/app2/clientid.jsonld>; 15 acp:agent <https://solidweb.me/Ellie-s-Pod/profile/card#me>; acp:issuer 16 <https://solidweb.me/> ] ]. 17 18 <#externalAgent> 19 a acp:AccessControl; 20 acp:apply [ 21 a acp:Policy; 22 acp:allow acl:Read; 23 acp:allOf [ 24 a acp:Matcher; 25 acp:client <https://solidweb.me/ClientPod/app2/clientid.jsonld>; 26 acp:agent <https://solidweb.me/EF-Pod/profile/card#me>; 27 acp:issuer <https://solidweb.me/> ] ].
The policy in Fig. 3 inspired by Clark-Wilson we have just shown can be implemented in ACP, but is not supported by WAC. While ACP gives us a vocabulary for defining policies, its secure usage is contingent upon the properconfiguration of ACP policies, particularly with respect to acp:client directives, as we elaborate on next. 2.3. Attack vectors when acp:client is omitted We explain an attack vector enabled when WAC is used or an ACP policy is configured insecurely. This proves that policies must stipulate acp:client unless data is sanitised.
Suppose a user intends for two resources to be exclusively accessed by two different apps, as
depicted in Figure 3. Failure to specify that a client (app) should exclusively access
resource X results in permitting bothapps access to X. The steps that acompromised
client may take to access resources not intended for them are illustrated by the message
sequence chart (MSC) depicted inFigure 5. The MSC not only clearlydisplays the
attack vector but also the interactions a user can have with their Pod. We assume,(
Authorisation Server
(
(
Using acp:client the attack vector in Figure 5 is preventable. Since the ACP policy is
able to state within the permissions which app can access a given resource within a Pod,
the attack vector would be blocked by theauthorisation server at step (
It may be possible to have a security policy model where DCR clients can access certain data. However, it should be known that such data should be sanitised inthe sense that it is fit for consumption by any app in the ecosystem that a usceornnecting to the pod may use. As we have seenpreviously in this paper, information without a policy that identifies clients, may flow freely through the system. This potentially means that private personal data should not be handled by sucahpps, or there is a risk of violating regulation such as GDPR due to exposure to data breaches involving a single compromised app in the ecosystem. Since personal data is a primary use-case for Solid, one must ask carefully the question of what counts as sanitised data. 3. Beyond Clark-Wilson: attacks when acp:issuer omitted Having explained the importanceof acp:client, we now explain another attackvector made possible by omitting acp:issuer from ACP policies. By specifying authorised Identity Providers (IdPs), the acp:issuer predicate restricts authentication and access privileges solely to designated IdPs trusted by the pod. Without stipulating acp:issuer threat actors could exploit any compromised IdPs listed in a WebID to issue fraudulent tokens, thereby gaining unauthorised access to Pod resources without the knowledge or consent of the owner of the WebID.
Consider the MSC diagram in Figure 6. In this attack vector, a user does not need to request access nor does an honest client(app). The user has however listed a compromised IdP in their WebID that would not be acceptable for accessing the pod. Here we see that a compromised IdP can simply generate a DPoP token themselves and spend it to access a resource within the Pod, without contact the user of app listed in the ACP policy. Once again, the authorisation server checks the ACP policyand, assuming the issuer (IDP) has not been stated within the policy beforehand, access is given to the resource.
To block this attack vector, the predicate acp:issuer can be added into the policy to prevent this attack vector from occurring with an arbitrary IdP. This way a pod can list explicitly which IdPs it trusts sufficiently to serve as a root torfust, for access to the pod. That is, the IdP is trusted not to exploit it position and also to put in place adequate measures to avoid becoming compromised, e.g., through cyber attacks on the IdP itself. Note that issuers were not part of the Clark-Wilson security policy model.
Compromised IDP (attacker)
gives access to resource
Towards trusted security policy apps & Conclusion We have seen, given the attack vectors in Figures 5 and 6, that using ACP is in itself not sufficient to ensure that the policy set for a Pod is guaranteeing reasonable confidentiality and integrity properties. Pod owners really need to set a policy that adheres to an appropriate security policy model, and that requires expertise that almost certainly the pod owner will not possess and quite possibly nor will most app developers. As a way to address this challenge, we develop a prototype security app as a proof of concept for a special highly-trusted app that sets a security policy on behalf of the pod owner.1 The security app must have the privileges to control the policy, by setting a policy with the access mode acl:Control for any part of the pod that the app is intended to manage and by naming explicitly the security app using acp:client. Indeed, it makes sense that when the pod is created the security app that is permitted to manage the policy of the pod is coupled with the pod by setting an appropriate policy. An organisation hosting such a security app must therefore be trusted above all other apps used – perhaps the pod provider that is anyway entrusted to properly manage the data in the pod, or an organisation trusted for its security practices.
Vulnerabilities discussed in Section 2 resulting from the absence of acp:client in ACP policies are critical since they may result in confidential personal data leaking to compromised apps. This paper also points out that this is a problem as old as enterprise computer security by drawing parallels with the Clark-Wilson security policy model. For a more recent example of a security policy model where more than the user is taken into account, observe that the Android security policy model is sensitive to the user, platform,
and developer as well as the appwhen determining whether access is permitted[10]. Rich policies are inevitable when many organisations are responsible for daecentralised ecosystem. In the case of Solid, we,in addition, pointed out in Section3, that the IdP has disproportionate power to access resources, if compromised. Hence we recommend that policies protect further resources by stipulating which IdPs are trusted, rather than leaving the user to decide.
A key challenge is that pod owners do not have the relevant expertise to manually set and check their ownpolicies. Priority future work that this paper exposes itshe need to agree on a precisely definedsecurity policy model for Solid. A security policy model goes beyond simply using ACP in the sense that it should enforce correucstage of ACP to adhere to confidentiality or integrity goals. An example of sucha goal is to avoid unintended information flows between apps controlled by different organisations, as discussed in this work in a particular instance. Drawing inspiration from Clark-Wilson is just a starting point towards this aim.
Acknowledgements This article is partially funded by the COST (European Cooperation in Science and Technology) Action on Distributed Knowledge Graphs (CA19134).