Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loss of Control Mitigation #67

Open
kjetilk opened this issue Sep 24, 2019 · 23 comments
Open

Loss of Control Mitigation #67

kjetilk opened this issue Sep 24, 2019 · 23 comments

Comments

@kjetilk
Copy link
Member

kjetilk commented Sep 24, 2019

As noted in #58 , we need a strategy to address the situation where a user is locked out from their pod through errors in the ACL. This can occur in several situation, e.g. syntax error in ACL files, that users pass end up not granting control permission to any agent, etc.

We have server-side validation to mitigate the former, and we have discussed introducing the concept of an agent that is understood to be the "owner", to mitigate other situations. We should have a more general discussion on it.

@dmitrizagidulin
Copy link
Member

In addition to missing or malformed ACL resources (especially the root storage ACL), loss of control (user being "locked out" of their account or storage space) can also occur from the deletion of several important resources:

  • Deletion of the WebID Profile document (prevents the user from being able to authenticate)
  • Modification of the WebID Profile doc to remove a few key triples (location of storage, and authentication-related triples)
  • Deletion of the root .meta resource. (This one's weird, but we currently store the recovery email for a user's account in the root /.meta resource. Not sure how that came about, but we should probably change that.) - renders the user unable to change their password etc.

@kjetilk
Copy link
Member Author

kjetilk commented Nov 27, 2019

@justinwb has somet thoughts on how to use meta resources (#102) to address this.

@csarven
Copy link
Member

csarven commented Jan 25, 2021

re critical changes to the WebID Profile description:

Modification of the WebID Profile doc to remove a few key triples (location of storage, and authentication-related triples)

We may need the notion of "update-only properties" ie. clients are only allowed to update the object of a statement, but never remove the statement or the subject-predicate pair(s).

"update-only properties" is clearly different than than how "server-managed properties" are handled as well as what "write-once properties" (as LDP calls it).

@gibsonf1
Copy link

Concerns as a Pod service provider:

It should be impossible for the user to compromise their account functionality in any way with the exception of an intentional account deletion.

To that end, there are several triples that the system requires and user should not be able to modify in any way. Some examples are:

<https://frederick.trinpod.us/@>  
    solid:account <https://frederick.trinpod.us/> ;
    solid:oidcIssuer "https://trinpod.us"^^<xsd:string> ;
    solid:privateTypeIndex frederick:t_72 ;
    solid:publicTypeIndex frederick:t_6x ;
    space:preferencesFile frederick:t_8d ;
    space:storage <https://frederick.trinpod.us/> ...

I think state level permissions are needed to solve problems like system vs user data on the same resource, where a state is a uri representing a triple.

Additionally, system level containers like / /inbox /profile etc should also not be modifable by the user. Our work around for this is adding a system control acl to required containers and disallowing any user changes to those containers.

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Jan 25, 2021

To that end, there are several triples that the system requires and user should not be able to modify in any way.

Note that this is only one possible solution (and an undesirable one, as I want the ability to switch OIDC providers).
Other solutions exist; some within LDP, some outside.

@gibsonf1
Copy link

Ruben,

So you are objecting to the one triple about solid:oidcIssuer, not the others and the general concept about protecting system triples from user editing?

@RubenVerborgh
Copy link
Contributor

Objecting to all; that was just an example. There are good reasons to change any of those.

We need to understand that automatically determining which triples lock a user out is an intractable problem; assuming the existence of any solution in that direction is a fallacy.

@gibsonf1
Copy link

gibsonf1 commented Jan 25, 2021

Ruben,

I guess I'm missing how these triples have any meaning outside of a specific system and why a user would ever want to change them? :

<https://frederick.trinpod.us/@>  
    solid:account <https://frederick.trinpod.us/> ;
    solid:privateTypeIndex frederick:t_72 ;
    solid:publicTypeIndex frederick:t_6x ;
    space:preferencesFile frederick:t_8d ;
    space:storage <https://frederick.trinpod.us/> ...

These define a specific Pod in a specific system. The user, if they want to move their pod to another provider, the other provider would have different values for these woudnt' they? So the user has no role in them unless I'm missing something?

I would envision an import process to move a pod from one provider to another, where the new provider would change system triples if/as needed.

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Jan 25, 2021

I guess I'm missing how these triples have any meaning outside of a specific system

They do:

<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/solid/terms#oidcIssuer> <https://drive.verborgh.org> .
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/solid/terms#publicTypeIndex> <https://drive.verborgh.org/settings/publicTypeIndex.ttl> .
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/solid/terms#privateTypeIndex> <https://drive.verborgh.org/settings/privateTypeIndex.ttl>
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/pim/space#preferencesFile> <https://drive.verborgh.org/settings/prefs.ttl> .
<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/pim/space#storage> <https://drive.verborgh.org/> .

source: https://ruben.verborgh.org/profile/

Spans the systems https://ruben.verborgh.org/ and https://drive.verborgh.org/.

These define a specific Pod in a specific system

They would if identity and storage were tied. As my example above shows, they are not.

@gibsonf1
Copy link

I don't list the OIDC triple in the last example set as you have a good point on that, the others are my question now.

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Jan 25, 2021

Same answer.

<https://ruben.verborgh.org/profile/#me> <http://www.w3.org/ns/pim/space#storage> <https://drive.verborgh.org/> .

means: I (https://ruben.verborgh.org/profile/#me) use as storage (http://www.w3.org/ns/pim/space#storage) the space at https://drive.verborgh.org/.

Tomorrow I might (literally) change that to https://css.verborgh.org/.

@gibsonf1
Copy link

Those triples are stored in drive.verborgh.org. So to change them, it means they are being stored somewhere else, and my point is the somewhere else system should be changing them as needed on import - normal non-geek users could never handle that sort of thing, and why should they - those are a function of the system hosting the pod.

@RubenVerborgh
Copy link
Contributor

Those triples are stored in drive.verborgh.org.

They are not.

somewhere else system should be changing them as needed on import

They are not moving.

@gibsonf1
Copy link

Ruben,

Could you explain the context of those triples, where they are, what the use case is?

@RubenVerborgh
Copy link
Contributor

As I wrote above, I have multiple Solid spaces.

The triples are stored on ruben.verborgh.org.
They currently point to drive.verborgh.org as storage.

I need the ability to change my preferred storage location to anywhere I want. In fact, it so happens that I have just set up https://css.verborgh.org/ as a new pod today. So I might literally change that triple tomorrow.

Hence, we cannot prevent people from changing such triples, as valid use cases exist.

@gibsonf1
Copy link

So what you're talking about is a sort of Pod dashboard index if you will, that dispatches as needed to different things. Basically a config file. But in the production world of mass users, if you had such a system to dispatch on demand to different pods, it would also not be user editing of turtle but automated system configuration.

@RubenVerborgh
Copy link
Contributor

it would also not be user editing of turtle but automated system configuration.

Exactly. So that system needs to be able to; hence, we must not prevent modification of such triples.

Hence, users can lock themselves out. It's not a problem we can solve on the triple level.

@gibsonf1
Copy link

For TrinPod, we will be preventing users from destroying their pods as if they destroy their pod, they would be pretty mad at us about the fact that they inadvertently could. So we will put acls on states/triples that should not change inside their pod. Your case is a very different scenario and not inside a specific pod.

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Jan 25, 2021

That's all fine; just not something we want in Solid in general.

@gibsonf1
Copy link

No worries, I guess we will differentiate ourselves by users not having their pods corrupted by accident.

@RubenVerborgh
Copy link
Contributor

RubenVerborgh commented Jan 25, 2021

But at the same time also not giving them the option to use external storage. That's fine; it's a trade-off.
With great power comes great responsibility.

And as I wrote, other mechanisms exist. Allowing changes to those triples and non-corruptible pods are not mutually exclusive.

@gibsonf1
Copy link

gibsonf1 commented Jan 25, 2021

Our app will support any Solid Pod service (other storage), I'm just talking about the user that chooses us as storage, and not wanting to let them mistakenly mess it up. So I guess I don't see how we reduce any user options - they can not use us for storage, they can use us and other providers and link them together through our app, etc

Ruben, I agree, I'm sure Pod providers will take their own measures to protect users from themselves as needed, even if spec does not require it.

@elf-pavlik
Copy link
Member

elf-pavlik commented Jan 26, 2021

Please correct me if I'm wrong but enforcing shape validation on WebID document would ensure presence of needed triples by defining it in the shape which the document would need to validate against.

To avoid deleting WebID document all together we may need a way to distinguish write between update and delete. Than disable delete access on WebID document. This would allow updating it, as long as it validates, but not deleting it.

EDIT: You can find example of such shape in https://solid.github.io/data-interoperability-panel/specification/#shexAgent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: To Do
Specification
  
To Do
Development

No branches or pull requests

7 participants