Questions/issues about firefox snap (about confinement and launch method)

snap
1

Hi! I was trying to use firefox snap under kde plasma.
And experienced some weird behavior that might be severe and need a closer look. Since firefox snap is used by lots of people, I think it would nice to check it with you guys first.

System detail

OS: ubuntu 18.04
D.E: plasma 5.12.8
app: firefox-snap
snap-version: stable(243)/beta(246)
issues:

  1. crash when open file dialog
  2. pinned instance coexist with the .desktop instance
  3. ignore confinement when launched from /snap/firefox/current/firefox-bin

1. crash when open file dialog

At the beginning, I was facing the issue of snap not respecting the theme. My firefox(launched via .desktop file) would crash when opening file dialog. It leaves an error message of:
Error loading theme icon 'dialog-question' for stock: Icon 'dialog-question' not present in theme breeze

Since there are not breeze-icon-theme under gtk-common-themes, I tried to set icon themes to Yaru under kde system configs–>gtk styles.

Similarly, I got the exception of: Error loading theme icon 'dialog-question' for stock: Icon 'dialog-question' not present in theme Yaru The same has been done with adwaita installed(both icon/theme) with the same exception.

2. pinned instance coexist with the .desktop instance

By accident, I pinned firefox to the plasma taskbar and found out that, If I launch firefox from the taskbar instead of from the launcher, firefox would pick up the correct theme.

As I believe the correct behavior for snap app would store it’s config in ~/snap/firefox/common/…, I’ve noticed that the pinned version and the .desktop version can be launched side by side while using different profile.

I’ve found that the pinned version read/write it’s profile into ~/.mozilla/firefox/some-profile, which is the default behavior for the deb/tar.gz version when launched by user account.

3. ignores confinement when launched from /snap/firefox path

With the findings mentioned above, I tried to launch the app by creating a new desktop from the menu editor and set the exec path to /snap/firefox/current/firefox-bin, and it picks up the profile the pinned version used. Which lead me wonder if other snap restrictions are lifted as well.

Unfortunately, the answer is yes. If I disconnect firefox from the camera plug, the original version would not allow me to use the camera. However, for the newer one that launched by /snap/firefox/…, I can not only use my camera, but bypass other confinement such as removable medias and such.

The whole experience feels strange since snap was supposed to be solid and secure since it’s the biggest selling point for me.

Really hoping this was a false alarm. It Would be nice if someone can help me figure this out, I really want to use snaps for the foreseeable future.

2

  1. This issue sounds similar to another one in the evince snap that was investigated a while back.

  2. It looks like the pinned version picked up the desktop file for the firefox deb package (firefox.desktop) instead of the one installed by the snap (firefox_firefox.desktop). I’m not familiar with how app pinning works in plasma, but this proposed change might help.

  3. The only supported way of launching a snap app is snap run appname or snapname.appname (sometimes shortened to appname if snapname and appname are the same). By running /snap/firefox/current/firefox-bin you are indeed bypassing confinement by not using snapd at all. This is dangerous, not supported, and you’re “lucky” that it worked at all. Snaps are solid and secure when used as intended.

3

this (unsupported way of starting it) only works because you have the deb version (and thus all required dependencies) installed outside of the snap … had you only the snap package installed launching it like this would fail because it would not find its libraries (and you are also lucky that the versions seem to roughly match).

4

Thx for your reply, glad it’s discovered by someone else, hope it gets better.

5

Thx for your reply, if that’s all it takes to successful launch it, I guess I’m luck that day.
Although I understand that it was a edge case, it still feels a bit weird.

I was thinking that, if a potential malicious user figured that the system happens to have the dependency and the snap version aligned, although it won’t make the snap version less secured than the deb version, it would make it equally dangerous. For open source projects that might be solvable from the upstream or directly via source, but for legacy software or proprietary software, if lucky enough, wouldn’t someone be able to find exploits to the host system?

The above case is just made up by me, I’m no security experts, just trying to understand snap. I was expecting launching from the /snap/app/path need to pass all the checks from snapd too.

6

as you stated a few lines above already, if someone has the deb and its dependencies installed at the same version level, directly executing the binary inside the snap is exactly as secure or insecure as executing the deb … it doesnt make any difference from an attacker or security POV then.

one thing to keep in mind though is that the binary in the snap is always on a readonly filesystem so it can not be modified/hacked …

8

I just found out that my title might be a bit misleading/scary for the interweb people.
Any suggestion that for the title that aligned to the forum posting style?

9

I forget about the read-only filesystem part, glad there’s other safeguards.

10

Given that your 3 points are totally separate issues, ideally they would have been separate threads.

What about “questions/issues with the firefox snap”. That’s rather generic, but search engines these days do a good job of surfacing the relevant content from the discussion, not just the title. Definitely less scary.

11

Good opinion, would raise question better next time.