Request to allow snap-store to auto-connect to password-manager-service and snapd-control interfaces.
The snap backend for the snap-store snap requires access to the keyring as well as access to snapd to install and remove snaps.
Name: snap-store
Publisher: canonical
URL: https://dashboard.snapcraft.io/snaps/snap-store/
If we talked about this before, I apologize for forgetting the details.
The snap today is allowed the use of classic. It sounds like you are trying to make this a strict mode snap, and so it seems quite reasonable that it needs to talk so snapd to add/remove software.
I donât understand why the snap-store would need access to the keyring? Can you elaborate on why it is doing this? I figured there would be some âsnap loginâ or polkit dialog for this instead of reaching into the keyring for stuffâŚ
Yes, the intention is to ship as a confined snap rather than classic. Without connecting to the password-manager-service interface the snap backend doesnât find any installed or available snaps. Looking at the code, itâs using libsecret to store a token. I didnât see the snap backend requiring that, but it doesnât work without access. I can look at the code further if necessary, but libsecret isnât an optional dependency.
Iâd like to better understand what it is storing/accessing via libsecret before voting to auto-connect.
GNOME software stores all GsAuth objects using libsecret. The only auth methods that are implemented are Ubuntu One and the snap store. So itâs currently storing an OAuth token and the snap macaroon.
libsecret keys are âusernameâ, âpasswordâ and any other keys that a GsAuth object defines (âmacaroonâ in the case of snap).
FYI, I granted the auto-connection for snapd-control already.
I really hate secret-service when used with snaps since it is not designed with application confinement in mind. Any snap that uses it has access to all other snapsâ data that store info in the db. Therefore, a confined snap that is granted use of password-manager-service now has access to the snap store macaroon. Is there some way it could store this off securely?
Granted, this is no different from when gnome-software was a classic snap and storing stuff there, so Iâll give a +1 to auto-connecting password-manager-service. But I donât like it.
@niemeyer, @alexmurray, @roadmr, @kyrofa - can one/all of you vote on the auto-connection of password-manager-service?
+1 to snapd-control. I still feel quite uncomfortable with auto-connecting password-manager-service to anything. @jdstrand I see your logic regarding how the alternative is a classic snap, but at least a classic snap requires one to explicitly opt-in to the risk of installing it. By strictly confining it but granting auto-connection to password-manager-service, I feel like weâre hiding the risk of that interface. If we had a way for users to override auto-connections Iâd feel differently, but this prevents even the cautious users from being cautious. Iâm a soft -1 to this, but I might be persuaded with a little more conversation.
is there a way to namespace data in secret-service (prefix username?), or could we make a trivial intermediary?
Applications do that, but as part of DBus member data, so it is not mediatable/enforceable. A proxy could solve this, but it would need some design.
1 (tentative) vote for, 1 against. We need a majority with at least two votes in favor to grant.
@niemeyer, @roadmr, @alexmurray, @Wimpress - considering previous comments in this topic, can one or more of you vote on auto-connecting password-manager-service?
As far as this snap is concerned, the outcome is still better when strictly confined - so I am happy to vote +1 for auto connect for both interfaces.
In general a better solution is needed for password-manager-service but this is a future enhancement.
There is no additional risk to a user installing snap-store as strict with auto-connect of password-manager-service since it is just accessing the existing credential - not storing a new one - so they arenât exposing themselves to any extra risk.
Kyleâs comment is spot-on:
The lack of warning for an autoconnection vs. the warning we do have for classic snaps is partly why we denied this request.
Mainly due to:
Whatâs interesting here is that a warning for the user to consider whether to connect the interface would be âif you autoconnect me (the snap-store snap), then other snaps with password-manager-service can steal my secret dataâ.
Iâm thinking of the implications of the store macaroon being grabbed by another malicious application and which damage it could do; I think itâs not a huge risk at this point because for a normal user, the macaroon only allows relatively harmless operations such as downloads, refreshes, information requests. However, if down the line the macaroon is tied to permissions to download/use commercial snaps, it might become a more valuable target for attack. So in general, putting data in password-manager carries risks that should be considered.
Iâm +1 to granting password-manager-service autoconnection because within the context of this snap which has a clear purpose and is by a well-known and trusted publisher, it makes sense. But I would urge @kenvandine to seriously consider the risks and advice mentioned in this thread. Essentially itâs a âok, sure, you can go into the woods if you want, but be warned there are wolves in there, so up to you if you want to risk it; if not, either donât go or get weapons/protectionâ.
One thing to note here is that gnome-software will never be putting a store macaroon in gnome-keyring. Instead, it will be a snapd macaroon. For example:
>>> import json
>>> import base64
>>> with open('/home/james/.snap/auth.json', 'r') as fp:
... macaroon = json.load(fp)['macaroon']
...
>>> macaroon += '=' * (-len(macaroon) % 4)
>>> base64.urlsafe_b64decode(macaroon)
b'0013location snapd\n0011identifier 1\n002fsignature ...'
It is just a signed reference to a âuser ID 1â inside the local snapd. So yes it is sensitive (assuming you can talk to /run/snapd.socket), but it has no meaning if transferred to another machine.
Itâs also worth noting that we only ever try to generate a snapd macaroon if we need to perform an operation where polkit auth is not sufficient. So in many cases there is no macaroon to expose.
Awesome! That makes me more at ease with this and shows you did think about the implications (actually even more than I did! thanks for clarifying).
My +1 stands, of course 
3 votes for, 1 against for password-manager-service. Granting auto-connection. This is now live.