1Password would like to request an auto-connection for the password-manager-service interface to our Snap.
We’re aware that many requests for the same thing have been turned down in the past. With that said, we think that our use cases differ enough for consideration. We do not actually use use the desktop environment’s keyring as part of our password manager; rather, we use it to persist auth tokens for any 1Password accounts which have 2FA enabled. This acts only as a nicety to avoid MFA prompts every time the application unlocks, and to provide a nice integration with the platform.
1Password only inserts and deletes these account specific items, along with doing a scoped scan for items with a matching, application specific, type. 1Password never stores anything that isn’t already fit for storage on-disk in plaintext, and never reads unrelated items contents.
I am not averse to granting this, however there is some risk in that it then exposes whatever tokens 1password stores in the keyring to other apps / snaps which have access to this - traditional (unconfined) apps can access the keyring without any authentication and hence read / modify whatever any other app/snap stores there. So whilst 1password is a trusted publisher, I don’t see a problem with granting this for it’s use and trusting 1password to do the right thing, however I would like to know if you see this as a potential security risk to 1password itself from other apps on the user’s desktop?
Thanks @alexmurray. We are aware that all apps have access to the keyring, which is why we don’t use it for real secrets which are either kept in memory or encrypted at rest.
For our use case, the keyring is simply a persistent store for an auth token that we would otherwise keep In plaintext. It is not an encryption key and provides no value to an attacker without a key.
Since any user process would be able to read or modify this token regardless of where we put it, the security model doesn’t change from our perspective. The keyring is just a more deliberate and and appropriate storage location for this data than a file or a database.
Thanks for the detailed explanation. In this case I am still a bit concerned about granting auto-connection to password-manager-service. iiuc, the auth tokens you are willing to store are only created and used by the 1password snap so I would prefer to have it managed in a location private to the 1password snap only. This way we are not opening the attack surface with an use case that does not really need it meanwhile we preserve the user’s voice in this very sensitive access.
Since 1password is a trusted publisher, can other @reviewers please comment?
