[18.0][IMP] vault: mandatory custodians

[jans23]

Add a setting 'Mandatory Custodians' listing users that are automatically added to every newly created vault with read + share permissions. These custodian rights cannot be removed and their share permission cannot be revoked, ensuring administrators/custodians retain access to e2e-encrypted vaults (e.g. when an employee leaves).

[fkantelberg]

I don't really like this feature and have concerns. It weakens the security by design and looks like a backdoor user to every vault (even private vaults). I already talked about that with @jans23 and his main concern was to allow it as a backup user to now loose the content of such vaults (correct me if I summarize it wrongly). There are some options how you loose access of the vault:

Option A) Somebody removed you from a share. In that case the entire vault might be re-encrypted and you can't decrypt the master key anymore. You still have access to your private key. If the vault is shared with you again you have full access again. If you go the database route you can restore it with the regular backups to the state before but you won't get access to secrets stored after the removal of your key. If somebody removed you which shouldn't happen the share permission might be given to the wrong person.

Option B) You can't decrypt your private key anymore because you lost the password. For vaults with other people you can invalidate your key and ask for a re-invite. If nobody is allowed to share this can be technically done via the database. If there is no other person in a vault all content is gone and you failed to use a password manager. You should think about a better strategy to keep this important password. This might be the only case this feature might solve.

Regarding the code: There might be a problem when you delete a vault because you can't remove any vault.right with the custodians.

[jans23]

The scenario which is addressed by this MR is that C) an employee leaves the company for whatever reason (e.g. quit his job, got fired, truck factor). In this case the company may want to keep access to relevant accounts in the business context. A custodian would be in the position to decrypt the employee's vault and re-gain access. This is a legitimate demand and sharing to custodians is transparent as it is with any other user today. Every organization can decide if they want to configure custodians or not so this MR doesn't make anything worse but introduces just an option.

I added a regression test which deletes a vault being shared with a custodian. The test passes so I think it's not an issue.

[fkantelberg]

This is what I called private vaults and you basically want to enforce that a 3rd person is always reading in an E2E scenario. Making it transparent doesn't make it any better. The company has the decision but you are taking it from the user. Furthermore this opens a new attack surface on the vaults (what if a person with too many rights just decides to add himself to the custodians).

From my perspective: This should be handled with a policy and not with a backdoor user. If such business related secrets are lost because an employee leaves you have different problems (e.g. that crucial access isn't mirrored already). Most times admins can gain access to the mail account and do the password reset procedures in various places. If I would personally notice some E2E application to do that I would leave it and switch the application (e.g. go back to a normal keepassxc again where you also can't access it).

If you really need it and find support in the community (I don't support it) please leave it out of vault and create a vault_custodian so one can decide to not install this stuff.

[pedrobaeza]

I agree with @fkantelberg. In the scenario described, you can just change Odoo user password, being an Odoo administrator, and login with that user, and then show, change or remove what you want in that vault.

[fkantelberg]

That won't work @pedrobaeza . You can't decrypt the private key without the password used for it and this password can differ from the login password too. You can remove stuff but not access or share with others.

[pedrobaeza]

Oh, true, I have mixed things. Indeed, you have your personal decrypt key at client level.

[jans23]

Here is this feature in a separate module: #998