[Bug] Latest testing, group permissions allows user role to delete password entries (and revoke password collections) via extension.

[jb2barrels]

Subject of the issue

Latest testing, group permissions allows user role to delete password entries (and revoke password collections) via extension.

Deployment environment

• vaultwarden version: Latest testing

• Install method: Docker - vaultwarden/server:testing

• Clients used: 2024.6.2 (Browser Extension, Google Chrome)

• MySQL/MariaDB or PostgreSQL version: Postgres

• Other relevant details: Web vault properly shows password collection checkboxes as grayed out when attempting to modify a password entry's collections as the user role. On the Bitwarden extension, these boxes are not greyed out and allow you to succesfully update a password entry's collections. Additionally the user role is able to delete passwords in the organization.

Expected behaviour

User role should be unable to revoke collection permissions using the Bitwarden extension. Additionally I assume they should also be unable to delete passwords from the organization, unless they are a higher role?
Since the web vault works as expected for not being able to revoke an entries collections, I assume maybe a specific API call the extension does also needs to be updated?

Troubleshooting data

This is related to the changes after the following merged pull request:

• add group support for Cipher::get_collections() #4592 @stefan0xC (Which also related to [Bug] Group Permissions Collection Deletion Issue (Manager role) #4588 )
• The pull request fixed the manager role's ability to modify password entry collections, but instead traded off the issue with providing user's role more permissions then allowed.

[stefan0xC]

Can you please be more specific what the issue is or how to reproduce the issue? Because I'm not sure I understand it.

If I have a user that has only view permissions on a specific collection via a group (and no other write permission either directly or via another group) I cannot change items in that collection (and also not delete them so this seems to work as intended as far as I can tell). And if I try to add an item via the browser extension to a new collection (where I have write access) I'll get the error message "Cipher is not write accessible". (That the extension displays the collection as assignable when it is not is probably a bug in the client, not sure there's anything we can do about it.)

[jb2barrels]

@stefan0xC You may ignore the delete password entries part of my report - I believe I misunderstood the user roles regarding that part.

You will see in this example the test user has permission to modify collections on the extension which shouldn't be possible, but the web vault correctly does not have the permission to do so.

Additionally towards the bottom with screenshots, you will see a User is unable to add new entries to a vault which they have 'view only' permissions even though the User role indicates they should be able to atleast add entries. (You may correct me if i am wrong on interpreting this part)

---

---

Here is the detailed screenshots, incase this helps with replicating my scenario:

Username: TestUser
Organization Role: User (Access and add items to assigned collections)

User's permissions:

User's view of the vault, collections, and available entries:

---

Collections:

• TESTING-COLLECTION-CAN-EDIT-1
• TESTING-COLLECTION-CAN-EDIT-2
• TESTING-COLLECTION-CAN-VIEW-1
• TESTING-COLLECTION-CAN-VIEW-2

---

Groups:

• TESTING-GROUP-CAN-EDIT

  • Assigned Collections (With Can Edit)
    

• TESTING-GROUP-CAN-VIEW

  • Assigned Collections (With Can View)
    

---

Unable to add new entries as user to a 'Can View' as User role (User role defined as 'Access and add items to assigned collections)

---

Correct Behavior of editing password entries collection's per web vault:

Incorrect behavior of editing password entries collection's per web vault:

Same password entry '' with the ability to modify the collection entry checkboxes via the Browser extension on Google Chrome:

Entry confirmed to have been modified using extension (as viewed by the web vault):

[stefan0xC]

Thanks for the screenshots.

Unable to add new entries as user to a 'Can View' as User role

It seems very intentional that you can't add new items to a non-editable collection (or an organization, if you only have view permissions).

Correct Behavior of editing password entries collection's per web vault:

This seems wrong to me. If the item is in a can edit collection, why shouldn't you be able to change the collection of that item? According to https://bitwarden.com/help/user-types-access-control/ you should be able to "add, edit, or remove items from assigned collections, unless assigned Can view permission."

So to me it seems there are two different issues:
a) you can't change the assigned collections to items in the web-vault (whether or not you have the edit permission to a collection or even if you have been granted access to all current and future collections)
b) you seem to be able to change the collections of items in view only collections in the browser extension (which is prevented by Vaultwarden because you really shouldn't be able to)

[jb2barrels]

I'll see if i can compare sometime this week the permissions to how official Bitwarden does it on their WebUI/Extensions.
That way we can get concrete verification of what intended behavior we are expecting.

[jb2barrels]

@stefan0xC I have completed testing of permissions of the User role on the official Bitwarden instance, these were the results.

Test User - with User role in organization.

• Has 'Can Manage' access to collection 'TestCollection-CanManage'

  • Can add new Password Entry (Confirmed, can add using both Web Vault and Browser Extension)
  • Can delete entries from 'TestCollection-CanManage'
  • Can edit entries from 'TestCollection-CanManage'
  • Can restored deleted entries from 'TestCollection-CanManage'

• Has 'Can View' access to collection 'TestCollection-CanView'

  • Can not add password entries (Confirmed, collection 'TestCollection-CanView' is not shown as an available collection to add the entry to in both Web vault and Browser extension)
  • Can not delete entries from 'TestCollection-CanView'
  • Can not edit entries from 'TestCollection-CanView' (You can save - probably for the folder feature, but fields are greyed out for modification)
  • Can not update a view-only entry in 'TestCollection-CanView' to add it to another collection you have edit access to, even if you have Edit permissions to 'TestCollection-CanManage'
  • Can restore a deleted entry from the collection back into 'TestCollection-CanView'

[BlackDex]

Since we currently do not support the canManage feature via the interface this is probably going to rather difficult to fix in good way.

We need to overhaul the permissions anyway if we want to support the new roles and flexible collections.

This overhaul should also include a re-design of the groups/collections interaction and how the data is stored. Instead of storing everything fully normalized into multiple tables, we just need to store these items into one table where possible.

This should make the queries to determine if users should have access or not either via direct collection assignment or via groups easier.

But this has to be thought of in a good way.

[BlackDex]

@jb2barrels I just tested this and I am unable to reproduce this in anyway.
I verified it with an original Bitwarden account.

I'm just not able to edit any VIEW item in any way.
The only thing i can do is change the folder which is allowed and it will only change the folder and nothing else.
This is also possible via any client as far as i know, including the Browser Extensions or other clients.

Only pressing the save button and showing that it was saved doesn't mean the cipher it self was updated.
A totally different endpoint is used for these calls.

Here is a screenshot of the member groups and collections and the permissions:
Groups:

Collections:

And here the member list:

Since I'm really really not able to let a user edit any item within the VIEW collections/groups I'm going to close this.

If you are still able to reproduce this using the testing tagged images of Vaultwarden please provide more screenshots of the settings of the user, the collections and the groups.

And as @stefan0xC noticed, the part where you are saying the user is allowed to save a cipher are ciphers located in the EDIT collections/groups.