Classic confinement for hey-mail

[nabeelah]

hey-mail is an email service, for which I’d like classic confinement approval. There are two areas that make it problematic to run in strict mode:

• U2F key support: Even after adding and manually connecting the u2f-devices plug, I am not able to use a Yubikey when in strict mode. This works when the app has classic confinement. This is an essential feature for our security-focused email app.
• Accessing all directories: When using the file picker, users expect to be able to access all parts of their filesystem to, say, attach a file to an email.

[galgalesh]

What GUI toolkit are you using for the file picker? If you’re using GTK or Qt, you might be able to use the XDG desktop portal to access any files. The files portal opens a native file chooser on the host system and whichever file the user chooses, the snap gets access to.

You can also use the portals dbus API directly, if it’s not supported in the toolkit, though that probably requires significant changes in the application.

[roadmr]

If you look at how the yubioath-desktop snap is configured, it uses u2f-devices as you tried to do, but also raw-usb and hardware-observe. Maybe you can try with these interfaces?

raw-usb is kind of powerful/sensitive as it allows poking the usb bus but it should be preferrable / less sensitive than full classic confinement.

• Daniel

[nabeelah]

Ah, that sounds perfect. This is an Electron app though, and it doesn’t seem like there’s Portal support yet?

[nabeelah]

Thanks for the tip! I tried using only hardware-observe and u2f-devices (without the raw-usb connection),and it works perfectly for my use case.

[galgalesh]

No, it doesn’t yet, though you might be able to work with the developer to get it merged. Afaik, they are looking for developers of electron apps to test it out.

This is the latest update from the Canonical team about that support; they went a slightly different route.

Linux Mint 20 disables deb2snap packages, and Snap's growing external adoption problem

We did have a look at what would be needed to add portal support in Chromium, on the basis that this would eventually percolate through to Electron: Similar to that Electron PR, there was similar push back against simply porting over to GtkFileChooserNative, over concern for supporting old versions of GTK. Rather than using dlsym to check for those symbols though, the Chromium developers seemed to think coding directly to the portals D-Bus API would be a better approach to remaining compat…

[alexmurray]

I see the u2f-devices part of this has been resolved - regarding accessing any file - this is not a sufficient use-case for granting classic confinement - for the vast majority of use-case, plugging the home and optionally removable-media interfaces should be sufficient.

[jamesh]

It’s also worth noting that it will be much easier to test your application with strict confinement compared to classic confinement.

With a classic confinement snap, it can be difficult to ensure you don’t end up linking against libraries from the host system. This can lead to breakage on systems where those host libraries are incompatible with the systems you tested your snap on.

In contrast, a strict confined snap will see the same libraries on any system it is deployed to. It doesn’t completely eliminate the possibility of compatibility problems, but it greatly reduces it.

[nabeelah]

Thanks for the feedback everyone! I’ll close this request in favour of an autoconnection request for those relevant plugs here.