Last week I worked with the Azure Storage Explorer team to create a snap. The storage-explorer snap requires the password-manager-service, all the storage objects are kept in the keyring.
I’d like to request (on behalf of the Storage Explorer team) that the password-manager-service is auto-connected to the storage-explorer snap. Without connecting this interface all previously connected storage object are absent each time the application is started.
As discussed previously, this interface is problematic (see Auto-connecting the cups-control and password-manager-service interfaces for the chromium snap where chromium was disallowed auto-connection). Keep in mind that not only does password-manager-service give the snap access to all of the user’s stored passwords in the keyrings, but it also gives all other snaps that connect to this interface access to Storage Explorer’s passwords.
-1 to auto-connect. Please keep in mind that GNOME Software in Ubuntu, the snap-store snap and possibly other snap installers allow setting this up on install. Also, the snap can quickly determine if the interface is connected on first launch and tell the user that the manual connection is needed to use the interface.
@reviewers - can others vote?
Would it be possible perhaps to set up and configure a keyring service inside the snap?
I agree with @jdstrand’s rationale: given how sensitive the information unlocked by this interface is, I think connecting it should be a conscious user choice (so -1 to auto-connect).
That said - are there alternatives we can suggest in order to ensure a friendly user experience? Other than installers allowing the user to make this choice at install time, the usual pattern is for the snap to contain a wrapper which checks for the interface and asks/guides the user to connect it at that time, while making the implications clear. Would this work for Storage Explorer?
Yes… though it might not have the properties they want. It depends on how they set up things. Usually secret-service/kwallet is only useful for protecting data at rest, after the user logs out/shuts off the machine and usually software stores keys in the ‘default’ or ‘login’ keyring so it is automatically opened on login. It in no way isolates applications from each other. Implementing some keyring service in the snap would not have this unlock upon login integration.
snapd could grow a secret-service/kwallet proxy so snaps only have access to their own credentials, but in the meantime I maintain that the snap should on first launch determine if the interface is connected and provide useful information to the user on why the interface is not connected and how to perform the connection. Auto-connection in some ways hinders the user’s choice since the user must seek out the auto-connected interfaces. Storage Explorer’s security-conscious users likely don’t want password-manager-service connected (or wouldn’t if they knew that other applications had access to the objects).
I certainly understand the implications here, and some alternatives might be possible. I’m a little new to Linux and Snapcraft; how might I go about creating a wrapper?
The major concern here is user experience. In the non-snap case, Storage Explorer throws a fatal error, because a libgnome-keyring0 package is missing. That, at least, gave you an idea of what was wrong. Currently, for the snap, not connecting the password manager results in a functional app that doesn’t “remember” any credentials. It’s not clear from the user’s perspective what’s wrong (not sure if that’s because we include libgnome-keyring0 as a stage-package for one of our Snapcraft parts).
The basic idea is that if your snapcraft.yaml you has something like:
apps:
foo:
command: bin/bar
plugs:
- password-manager-service
then create a shell script named ‘bin/bar.wrap’ (untested), adjust the snapcraft.yaml to use ‘bin/bar.wrap’ instead, and in it do:
#!/bin/sh
set -e
tell_user() {
...
}
alerted_user="$SNAP_USER_DATA/.advised-on-password-manager"
if [ ! -f "$alerted_user" ]; then
# XXX: https://forum.snapcraft.io/t/bug-1809708-allow-snaps-to-query-interface-connection-status-directly-from-snapd/9147
dbus-send --session --print-reply --dest=org.freedesktop.secrets /org/freedesktop/secrets org.freedesktop.DBus.Introspectable.Introspect >/dev/null 2>&1 || tell_user
touch "$alerted_user"
fi
exec /path/to/bin/bar "$@"
Then implement tell_user() using zenity or yad or something (you might find this and this useful). Hope this helps!
I’ll also note that chromium has a concept of using different password backends including basic (I think that is the name), gnome-keyring and kwallet. The application can be started with any of these via command line option, and basic defaults to an disk storage. Firefox has on disk storage which can also be protected via a master password to protect against offline attacks.
I don’t know if Storage Explorer has other storage options like the above, but thought I’d mention it since if it did, it could pick one or another based on interface connection, etc.
I’m not too familiar with what Azure Storage Explorer does and the extent to which it interacts with other applications on the system, is there ever an instance where the Storage Explorer would need to “share” it’s objects that are stored in the keyring with other applications on the same system?
I seem to recall some work being done in user session services (inside snaps that is) that are autostarted as that user when the user logs in, would that work here? Maybe @jamesh could comment on that…
No, Storage Explorer doesn’t interact with any other applications. The password manager service is really just a means of storing sign-in credentials we use to authenticate Azure requests. We use the keytar npm package to interface with the system’s password manager.
It would not help auto-unlocking the keyring, no, since that happens via a pam module and there are no snapd/pam integration points.
It looks like keytar uses libsecret, so the dbus-send command I gave above would be a way to see if the interface is connected or not. It doesn’t seem to implement other backends for Linux and does work with the default keyring (ie, the one that auto-unlocks upon login) afaics.
Somewhat helpful. Couple questions:
dbus-send for?storage-explorer app runs the command desktop-launch $SNAP/StorageExplorer. I’ve tried switching to a bin/start or a $SNAP/bin/start, but I keep getting “does not exist or is not executable” errors. Am I supposed to add a part or something?yad? Most of the chatter is for zenity, but my understanding is yad has less overhead.That said, it might be possible to have the application ship secret service, then on application start, create a private session bus, then fork off secret service on it (DBUS_SESSION_BUS_ADDRESS), then have keytar talk to it (it would use the same DBUS_SESSION_BUS_ADDRESS). This has an interesting property that on first launch after session start, the user enters the password to unlock the (private) keyring but thereafter storage explorer just uses the unlocked (private) keyring. In principle this should all work, but secret service might need some massaging to start in this manner and you might need to make adjustments in your code to only use your private DBUS_SESSION_BUS_ADDRESS for keytar functions.
This would be an interesting thing to explore (perhaps by the community), but the zenity/yad approach I outlined could be done quickly and immediately.
This is purely to workaround the fact that snaps can’t use snapctl to ask if an interface is connected at this time. The dbus-send tries to introspect org.freedesktop.secrets. If it can, it returns 0, if it cannot, it returns non-zero. So, if apparmor is blocking it, we expect to get the ‘1’ and then run tell_user().
You can ship $SNAP/StorageExplorer.wrap in your snap. Eg via the dump plugin:
parts:
dumper:
plugin: dump
source: files/
...
then put your wrapper in files/StorageExplorer.wrap and when you build it should end up in $SNAP. Then adjust your snap.yaml to use desktop-launch $SNAP/StorageExplorer.wrap and StorageExplorer.wrap to use as its last line exec $SNAP/StorageExplorer "$@".
I’ve not used yad personally, but @popey and others in the forum say it is easier. The snapcraft.yaml for the snap he mentioned in the thread I referenced is: https://github.com/snapcrafters/tmnationsforever/blob/master/snapcraft.yaml#L224. It doesn’t seem like he is doing too much (https://github.com/snapcrafters/tmnationsforever/blob/master/scripts/zenity, which is named ‘zenity’ but actually uses ‘yad’).
I must be doing something wrong, but I can’t figure it out what exactly. I have a small test snap defined here:
name: test-snap
version: "1.0.0"
summary: Just a test
description: Just a test
base: core
grade: stable
confinement: strict
architectures:
- build:on: amd64
parts:
test-snap:
plugin: dump
source: ./bin/
apps:
test-snap:
command: $SNAP/start
plugs:
- password-manager-service
And a directory structure like this:
I can’t build the snap unless I remove $SNAP/start and replace it with just start.
@lucyllewy or @sergiusens may be able to help there, but I also recall seeing something like this where $SNAP could be used as the argument to something but not in the command itself. Ie, command: foo, command: bin/foo, command: desktop-launch $SNAP/foo and command: desktop-launch $SNAP/bin/foo are all ok, but command: $SNAP/foo and command: $SNAP/bin/foo are not.
I don’t think there is any way to get the same user experience with a snapped user service. A big part of what makes the keyring work is pam_gnome_keyring.so, which unlocks the keyring using the user’s password on login, and reencrypts the keyring on password change.
Unless we also want to let snaps install PAM modules (which would be great for writing a password logger…), you won’t match that experience.