Trouble with Websockets in Snaps

snapcraft
#1

Hello,

A little while ago I started converting Enpass to a snap and I shared my progress here. I’ve now got 90% of the app working, even in strict confinement, but there’s one feature that still needs classic confinement to work. I thought I should start a new thread since this doesn’t look to be specific to my app but websockets in general.

Enpass is a password manager with two parts: the desktop app and the Browser Extension. From what I can tell, these two parts communicate exclusively on a websocket on port 10391-10395 depending on availability.

Under classic confinement, the browser and app communicate correctly. Under strict confinement, they do not. I tried figuring out which plugs I’m missing, but any network related ones didn’t help. The only thing I noticed is that sometimes snappy-debug displays the following message:

= AppArmor =
Time: Jan 13 16:25:37
Log: apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/DBus" interface="org.freedesktop.DBus" member="RequestName" mask="send" name="org.freedesktop.DBus" pid=48475 label="snap.enpass.enpass" peer_label="unconfined"
DBus access

I can’t really understand what’s going on, especially since, as far as I can tell, network usage isn’t restricted. I even tried to wireshark my internal network traffic but can’t seem to figure anything out. It seems as if both sides are responding. Here’s a link to a page containing logs from the enpass extension and the wireshark captures:

Here’s my snap.yml:

name: enpass
base: core18
version: '6.5.1.723'
summary: Unofficial Snap for the Enpass Password Manager
description: Offline Password Manager and Secure Vault. Saves and fill in all your passwords, cards and other details. Free for Mac, Windows and Linux.

grade: devel # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots

apps:
  enpass:
    command: opt/enpass/Enpass
    desktop: usr/share/applications/enpass.desktop
    extensions: [gnome-3-34]
    plugs:
      - home
      - audio-playback
      - network
      - unity7

parts:
  enpass-deb:
    plugin: dump
    source: "https://apt.enpass.io/pool/main/e/enpass/enpass_$SNAPCRAFT_PROJECT_VERSION_amd64.deb"
    source-type: deb
    stage-packages:
      - libxss1
      - libxkbcommon-x11-0
    override-prime: |
      snapcraftctl prime
      sed -i 's|Icon=.*|Icon=${SNAP}/meta/gui/enpass.svg|g' $SNAPCRAFT_PRIME/usr/share/applications/enpass.desktop
  snap-gui-folder:
    plugin: dump
    source: gui/
    organize:
      enpass.svg: meta/gui/

Please let me know if you have any suggestions, as I am still learning about snaps.

Thanks in advance,
Chris.

#2

You’re missing at least the network-bind plug which will let enpass create a “listening” socket for incoming communication. The network plug only lets outgoing sockets be created.

1 Like
#3

I was pretty sure I had tried that out… Either way, thank you for the reply. I tried it, and unfortunately it still doesn’t work. However, Enpass did report a different error in its logs!

1/13/2021, 5:28:04 PM : Connecting using websocket
1/13/2021, 5:28:04 PM : Opening connection on ws://127.0.0.1:10391
1/13/2021, 5:28:04 PM : Connection opened
1/13/2021, 5:28:04 PM : Connection established on port 10391
1/13/2021, 5:28:04 PM : Message parsed successfully
1/13/2021, 5:28:04 PM : Greetings from Enpass
1/13/2021, 5:28:04 PM : Self Initiating srp.
1/13/2021, 5:28:04 PM : Authentication required
1/13/2021, 5:28:04 PM : Termnating srp initialization process.
1/13/2021, 5:28:15 PM : Message parsed successfully
1/13/2021, 5:28:15 PM : App Different user.
1/13/2021, 5:28:15 PM : Closing connection
1/13/2021, 5:28:15 PM : Disconnecting Manually.
1/13/2021, 5:28:15 PM : Bug with 10391
1/13/2021, 5:28:15 PM : Connecting using websocket
1/13/2021, 5:28:15 PM : Opening connection on ws://127.0.0.1:10392
1/13/2021, 5:28:15 PM : Opening connection on ws://127.0.0.1:10393
1/13/2021, 5:28:15 PM : Opening connection on ws://127.0.0.1:10394
1/13/2021, 5:28:15 PM : Opening connection on ws://127.0.0.1:10395
1/13/2021, 5:28:17 PM : Error with connection after other user reported.
1/13/2021, 5:28:17 PM : Got Error
1/13/2021, 5:28:26 PM : Connecting using websocket
1/13/2021, 5:28:26 PM : Opening connection on ws://127.0.0.1:10392
1/13/2021, 5:28:26 PM : Opening connection on ws://127.0.0.1:10393
1/13/2021, 5:28:26 PM : Opening connection on ws://127.0.0.1:10394
1/13/2021, 5:28:26 PM : Opening connection on ws://127.0.0.1:10395

So I think this fixed the websocket issue but the app still doesn’t work right. Could it be that the app is detecting the sandboxing thinking it’s a different user?

#4

These two lines seem to indicate that you’re right in the thought that it is detecting different users between the server and client. If the enpass snap is launched by the user via a .desktop entry then this could indicate that it is not detecting the user IDs correctly (unsure whether it’s in the server or client)

#5

Yes, I have been launching the app through the .desktop entry. I also tried the enpass command through the terminal, as well as the /snap/enpass/x3/opt/enpass/Enpass command which launches the executable directly (although I think that circumvented the confinement). None of those worked.

What’s the best course of action now? I don’t have the source to investigate further. Should I attempt to contact the developers or try to apply for classic confinement in the store?

I should probably mark your first response as the solution given how that was the original question…