As a follow-up to that thread, can you please consider granting auto-connection to the following interfaces for the chromium snap?
Thanks in advance.
+1 for cups-control since people expect to print from the browser. It would be nice if this used the upcoming portals work.
Auto-connecting password-manager-service has benefits and drawbacks.
On the one hand, with it not connected the passwords are stored in effectively plaintext on disk (stored in an sqlite database to be precise), but they are protected with DAC and unavailable to other strict mode snaps. Systems not using disk encryption are vulnerable to data-at-rest attacks in the event of an offline attack.
On the other hand, connecting password-manager-service means that while the passwords are no longer stored in effectively plaintext on disk and are instead encrypted in the keyring to thwart offline data-at-rest attacks, the snap has access to the entire session keyring, not just those accessible to the snap (and therefore potentially all websites have access to all the passwords in the keyring if there are bugs in chromium). Other snaps that plugs password-manager-service also have access to chromium’s passwords.
A tepid +1 for auto-connecting password-manager-service. IMO chromium should instead manage its own password database and lock it with a master password, similar to how firefox does (though, not exactly like it does 
). It would be even better if the secret service/gnome-keyring/kwallet would become trusted helpers such that snaps could only access their own data. Neither of these are going to change any time soon (if ever) and users aren’t going to know about these finer points and limitations.
& days have passed but there aren’t enough vote to tally. @niemeyer, @roadmr, @ratliff, @evan, @kyrofa - can one or all of you cast your vote?
+1 for cups-control, but I’m generally -1 on ever autoconnecting the password-manager-service. I understand that chromium does the wrong thing in this case, but I’d rather see that fixed in chromium than just hand it default access to keyrings.
I’m +1 on cups-control. Printing from the browser is assumed to work.
I’m inclined to believe that the passwords inside Chromium are of greater value than the ones outside of it. It is unlikely in my view that something equal to my bank details would be held by a desktop application.
That is terrifying. I’m -1 on password-manager-service. Chromium should have its own encrypted database with its own master password.
3 votes for cups-control, 0 against. Granting auto-connection. This is now live.
1 vote for password-manager-service, 2 against. Not granting auto-connection.
I’m wondering whether the decision of not auto-connecting the password-manager-service interface should be revisited?
I understand the security implications and they are of course valid, but on the other hand for users that are being upgraded from the deb package to the snap, not having the interface auto-connected means that they suddenly see all their stored passwords vanish (they are still stored in the session keyring, but chromium cannot access them).
An alternative solution would be to not do the auto-connection at the store level, but do it in the deb’s pre-install script (which installs the snap from the store, and is executed as root). That has pretty much the same security implications though, so I’d welcome @jdstrand and others’ opinion before testing this.
I filed bug #1836616 to track the issue.
I agree, that UX seems rather poor. However, I don’t think it’s a reason to automatically connect this interface for everyone. The reasons against that haven’t changed, and to be honest this pain seems rather self-inflicted by the decision to automatically migrate deb users to the snap.
I also agree that the security implications of connecting the interface within the deb’s scripts keep the threat model the same as the deb. As a result, I think that’s not such a bad plan-- the users remain as insecure as they were, and the process is transparent, while users installing the snap also remain as secure as they are today.
This has the same security implications for the user upgrading from the deb to the snap, but not new snap users. You are right to point out that upgrading from the deb to the snap would be a major regression when the passwords are no longer available (which is a different story than a new user who is using chromium for the first time where chromium could more naturally guide the user). This seems to strike the right balance, though it is probably best if: a) the connection happens in a way that the user can discover (eg, echo for each connection) and b) this should only happen on upgrades, not apt-get install of the deb (which installs the snap).
Thanks for your input @kyrofa and @jdstrand. This is now implemented with https://bazaar.launchpad.net/~chromium-team/chromium-browser/eoan-stable/revision/1509 and https://bazaar.launchpad.net/~chromium-team/chromium-browser/eoan-stable/revision/1510, and is available in the chromium-browser package in 19.10.
The not-auto connecting argument doesn’t make sense to me. If Chrome is compromised and it has integration with libsecret, it doesn’t have access to anything except the secrets in libsecret which should be just master keys.
That is to say, you can decrypt other data owned by the session. That’s the understanding others using libsecret have.
To argue that you’re more secure by not integrating with libsecret is bizarre. Not just because no one uses the keyring if you buy that logic, but because every application will do what chrome does and encrypts with a hardcoded and arbitrary key and salt as a fallback. It’s still better than no encryption. So the two worlds here,
That’s your options. The rest of this seems to be over analysis unless I am missing something major and material.
As far as got the reasoning, the password-manager-service should not be shared with snaps which actually need a security sandbox. Is that right?
Is it possible for the password-manager-service interface to provide a means to restrict the service to a certain ~domain? E.g. to the snap name? Or provide a default implementation which does exactly that and can be autoconnected?
@EvanCarroll, you are saying that applications A can read application B’s secrets if both are in the key ring and it is unlocked (that is supported by the documentation) and so if A is compromised it can get the secrets from B, but that is better than having all applications not use the key ring and be subject to compromised machines (e.g. stolen HD or simply copied system files or etc.). Is my reading right?
Is it possible for the password-manager-service interface to provide a means to restrict the service to a certain ~domain? E.g. to the snap name? Or provide a default implementation which does exactly that and can be autoconnected?
I don’t know the answer to that question, sorry.
That’s exactly right. Let’s use a car as an analogy. It’s sandboxed from other cars, and doesn’t depend on other cars for its operation. You have two options: solder the key to the ignition, or put it on a keychain with your other keys.
If you put it on a keychain with your other keys, the ignition and car will have to see all your keys when you start it up. A potential vulnerability of sort. But it would be insane to solder it to the ignition and leave it with the car. That’s effectively what happens when integration with the key chain isn’t the default. The private key which is otherwise easily stored outside of the sandbox is now somewhere in the sandbox at all times. It may be less obvious then soldered to the ignition, it may be hiding in the glove box, but it’s trivial to find.
And this dynamic doesn’t get better if everyone solders their keys for vehicles to the ignition. While true, you can’t rob the owner and get access to all the vehicles, it’s only true because the vehicles have lost that security feature entirely.
Is it possible for the password-manager-service interface to provide a means to restrict the service to a certain ~domain? E.g. to the snap name? Or provide a default implementation which does exactly that and can be autoconnected?
You can have two keyrings one of which is manually unlocked. You can have snap create a locked keyring when the app is installed and make it available to the app when it’s run. But I think it would require app level modification because I’m not sure you can shadow the Login collection which is what most apps use. I could be wrong on all that though.
This would also break anything that relies on the less-secure default behavior. Imagine an application that wanted to read the Chromium Passwords and expected the key to be in the unlocked session/Login keychain.
To add some context the gnome-keyring situation changed since the initial review. when used from a snap (or flatpak) libsecret will default to store the secrets in a local file encrypted with a secret provided by the keyring, see https://github.com/flatpak/xdg-desktop-portal/pull/359 which should resolve the initial concern that the application would be able to access other secrets from the user keyring
The security team can take a look at this again, especially if the technical situation has indeed changed since the original decision was made.
when used from a snap (or flatpak) libsecret will default to store the secrets in a local file encrypted with a secret provided by the keyring
I just tested this by making a small snap that uses libsecret and without doing anything special, it added my secrets directly into the Login keyring (and would read from it), so it seems to me as though the default behaviour hasn’t changed, (unless of course I did something wrong). I did not specifically use portals.
Hi, I’ve been taking a look a look on this issue.
As @seb128 said, portals seems to be a great alternative in this scenario. They would allow snaps to store the information encrypted with a key provided by gnome-keyring, while considering the confidentiality of other secrets stored in the system. In fact, access to the secret-portal seems to be already granted by the “desktop” interface, which is already auto-connected.
However, as portals rely on the gnome-keyring version installed in the host systems, it only works properly when this version supports the secret-portal backend. I’ve been able to run a proof-of-concept in Ubuntu 22.04 and newer releases. So an option would be to use the secret-portal when present (it can be detected in the same way than libsecret does), and otherwise fallback to the current behavior.
