Auto-connecting the password-manager-service and snapd-control interfaces for the snap-store snap

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

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…

1 Like

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.

1 Like

I’d like to better understand what it is storing/accessing via libsecret before voting to auto-connect.

1 Like

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).


@jdstrand did Robert’s reply answer your questions?

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 Like

+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.

1 Like

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”.

  • Daniel

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 :slight_smile:

3 votes for, 1 against for password-manager-service. Granting auto-connection. This is now live.