-
Notifications
You must be signed in to change notification settings - Fork 2
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
text app can apparently bypass files_accesscontrol workflows #103
Comments
Trying this out with:
|
I had another look specifically at the PROPFIND result, which is what https://git.radicallyopensecurity.com/ros/pen-sunet-mfa-zones/-/issues/1 reports, and once usr1 toggles the MFA Zone switch, the PROPFIND result for Admin changes from 207 to 403 the next time they reload the page: |
Renaming this to be more specific about the text app, and splitting out ... to be about the related issue I'm investigating for remote access of files that should be blocked according to a files_accesscontrol workflow. |
It might be that when the text app looks at the filesystem, it does not go through the workflow engine. |
This might require some changes to the https://github.com/nextcloud/text |
Trying to dig deeper into the code with https://github.com/pondersource/nextcloud-mfa-awareness/tree/text-app |
Oh dear, there is a |
|
It seems to be doing some access checks in https://github.com/nextcloud/text/blob/d6947c8e36cd4e37f9efd96c57e218f3a480e4f8/lib/Service/ApiService.php#L111 and differentiating between shared and local files. |
I'm trying to force a bug into |
Ah, good! The text app create function does break on that. So maybe I'm just doing something wrong here:
Will continue debugging this tomorrow! |
So that's weird, the code seems to pass through the StorageWrapper but still in the browser you see updates arrive at the other end that should not be arriving. Will see what happens if you close and reopen the doc at the receiving end, that should then definitely give a "forbidden" error. |
To simplify the testing I'm going to put the text doc into a folder that is an MFA zone |
OK, opening a file inside an MFA zone for the first time is correctly blocked:
Similarly for the recipient creating a file inside the folder while it's a zone: 'Unable to create new file from template' |
And now it gets interesting:
Expected: sender can edit like they are the only person there, and recipient gets a sync error Actual: sender's edits appear in the recipient side! Also, sender sees the cursor (but not the edits) of the recipient. It's clear that there are some checks missing here. I'll test the same thing across two servers. |
Other tests:
|
Still not got sunet-nc3 working as an additional server in the test setup in the text-app branch of this repo
I'll do that for the basic file-access check though, then I can just do it in dev-stock where the TLS certs are trusted. |
Even the recipient logging out and back in doesn't stop them from receiving new updates if they browse back to a file that became MFA-protected after they had already opened it in the text app. |
OK so for text files inside an MFA zone it only happens until the recipient refreshes their screen. |
If I set a flow to block access to files names test.md then it does block access with the text app as soon as I refresh the screen. |
maybe the tags are only per user, so for a first user the file looks tagged but for a second user it does not? Testing that hypothesis. |
I'll add a rule where access to a file with mfazone tag is blocked for everybody, regardless of their MFA state. That would rule out that last hypothesis. |
Ah in that case it's correctly blocking! So that supports the hypothesis that this has something to do with the tags that the sender sees and the tags that the recipient sees. I had assumed that would be the same system tags, but looks like maybe it's not. Will continue tomorrow. Should also test this cross-server in dev-stock. |
As reported in https://git.radicallyopensecurity.com/ros/pen-sunet-mfa-zones/-/issues/1
Investigating
The text was updated successfully, but these errors were encountered: