Firefox snap home confinement appears to be ignored

snapd
1

Hello,

I am currently using the snap version of firefox with the home and camera connection currently disconnected.
image

Previously, this setup would not have access to anything in my home folder including dot folder access. Now I can access, read all the files within the directory and apparmor says nothing. This is with the home connection still disconnected.

image

When I run snap run --shell firefox, the confinement seems to correctly apply but I am guessing something here involving the gnome-3-34-1804 is allowing access to my home directory. This only seems to apply with the firefox snap.

This is on Kubuntu 20.04 with the latest updates.

Can someone help me with this.

2

I am getting these messages when I open the OpenFile dialog.

[11368.294991] audit: type=1400 audit(1591709112.680:514): apparmor=“DENIED” operation=“open” profile=“snap.firefox.firefox” name="/run/mount/utab" pid=12609 comm=“firefox-bin” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=0
[11368.298567] audit: type=1400 audit(1591709112.684:515): apparmor=“DENIED” operation=“open” profile=“snap.firefox.firefox” name="/run/mount/utab" pid=12609 comm=“pool-firefox” requested_mask=“r” denied_mask=“r” fsuid=1000 ouid=0
[11368.499945] audit: type=1107 audit(1591709112.884:516): pid=1445 uid=106 auid=4294967295 ses=4294967295 msg=‘apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/org/freedesktop/hostname1" interface=“org.freedesktop.DBus.Properties” member=“GetAll” mask=“send” name=":1.173" pid=12609 label=“snap.firefox.firefox” peer_pid=14874 peer_label=“unconfined”
exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?’
[11368.500003] audit: type=1107 audit(1591709112.884:517): pid=1445 uid=106 auid=4294967295 ses=4294967295 msg=‘apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/org/freedesktop/hostname1" interface=“org.freedesktop.DBus.Properties” member=“GetAll” mask=“send” name=":1.173" pid=12609 label=“snap.firefox.firefox” peer_pid=14874 peer_label=“unconfined”
exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?’
[11368.500058] audit: type=1107 audit(1591709112.884:518): pid=1445 uid=106 auid=4294967295 ses=4294967295 msg=‘apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/org/freedesktop/hostname1" interface=“org.freedesktop.DBus.Properties” member=“GetAll” mask=“send” name=":1.173" pid=12609 label=“snap.firefox.firefox” peer_pid=14874 peer_label=“unconfined”
exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?’
[11368.500111] audit: type=1107 audit(1591709112.884:519): pid=1445 uid=106 auid=4294967295 ses=4294967295 msg=‘apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/org/freedesktop/hostname1" interface=“org.freedesktop.DBus.Properties” member=“GetAll” mask=“send” name=":1.173" pid=12609 label=“snap.firefox.firefox” peer_pid=14874 peer_label=“unconfined”
exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?’
[11368.500215] audit: type=1107 audit(1591709112.884:520): pid=1445 uid=106 auid=4294967295 ses=4294967295 msg=‘apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/org/freedesktop/hostname1" interface=“org.freedesktop.DBus.Properties” member=“GetAll” mask=“send” name=":1.173" pid=12609 label=“snap.firefox.firefox” peer_pid=14874 peer_label=“unconfined”
exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?’
[11368.500269] audit: type=1107 audit(1591709112.884:521): pid=1445 uid=106 auid=4294967295 ses=4294967295 msg=‘apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/org/freedesktop/hostname1" interface=“org.freedesktop.DBus.Properties” member=“GetAll” mask=“send” name=":1.173" pid=12609 label=“snap.firefox.firefox” peer_pid=14874 peer_label=“unconfined”
exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?’
[11368.500901] audit: type=1107 audit(1591709112.884:522): pid=1445 uid=106 auid=4294967295 ses=4294967295 msg=‘apparmor=“DENIED” operation=“dbus_method_call” bus=“system” path="/org/freedesktop/hostname1" interface=“org.freedesktop.DBus.Properties” member=“GetAll” mask=“send” name=":1.173" pid=12609 label=“snap.firefox.firefox” peer_pid=14874 peer_label=“unconfined”
exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?’

I can still read all the contents and pdfs with no problems.

3

I suspect that Firefox is using the XDG Desktop Portals spec which allows access to files chosen by the user without requiring explicit filesystem access. This is done via a dbus protocol endpoint on your host which then marshalls the file into the sandbox and then back out again. In the future this is hopefully how many snaps will operate so that we can remove the automatic connection of the home interface.

4

Thanks for your reply. So is this currently intended behavior?

I was kind of liking the home permission mechanism as I could enforce the prevention of firefox from being able to read/send my .ssh folder.

5

Firefox cannot read anything in your home folder until you select it in the UI. The portals spec only exposes the file(s) you select. Firefox also cannot see what files exist in your home folder.

1 Like
6

no snap can read ~/.ssh unless it specifically declares a personal-files interface that you manually connect 
 the home interface, even when connected does not allow any app access to directories starting with a dot 


7

Is there any location that would be best to file a bug? At present it seems Firefox sometimes can access the portal file chooser.

For example, today I am getting this error in dmesg when it tries to spawn the open file menu. That seems to not work at all.

(firefox:11132): Gtk-WARNING **: 14:49:56.894: Can’t open portal file chooser: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.419" (uid=1000 pid=11132 comm="/snap/firefox/372/firefox " label=“snap.firefox.firefox (enforce)”) interface=“org.freedesktop.portal.FileChooser” member=“OpenFile” error name="(unset)" requested_reply=“0” destination=“org.freedesktop.portal.Desktop” (bus)

8

Disabling firefox:desktop connection removes file selection/access, so I guess that has changed.
I would like to be able to download files to a single dir on the filesystem while preventing firefox to access other files. Any ideas about how that could be achieved?

9

As mentioned elsewhere in this topic, unless the home interface is connected, firefox cannot access the files on its own (ie without the user driving file selection) when it is using portals. As such, on a firefox that supports portals (I think it is the one in stable now, but others can comment), you should be able to snap disconnect firefox:home and then just save your files in ~/snap/firefox/common. Firefox will only be able to access files in ~/snap/firefox (and a few things necessary to run, like input methods) from the user’s home directory “behind the scenes”. If you are worried about malicious sites and bugs in firefox, the worst firefox could be made to do with files outside of ~/snap/firefox is to trigger the portals file selector to display (but firefox itself can’t interact with the file selector).

That said, it seems like there is still a rough edge or two in the snap since I tried this and the snap seemed to make some assumptions about things. Once I was able to convince it to download to a directory in ~/snap/firefox/common, it worked mostly fine.

10

hmm interesting. I was not aware that firefox itself can not access a file in home dir if firefox:desktop is connected and that user interaction is needed. Thanks for that info, I’ll investigate more how portals work, this made me curious about the whole approach :slight_smile:

When it comes to rough edges, here’s one :slight_smile: The integrated pdf viewer can not download the pdf file, it even doesn’t show the download dialog. When firefox:home is connected, everything works fine.

11

I think this might be because it is downloading to one of the symlinks that are setup in ~/snap/firefox/common, eg ~/snap/firefox/common/Downloads -> ~/Downloads. AppArmor resolves symlinks so the file access is determined to be ~/Downloads and thus denied. You should be able to confirm this with journalctl to examine the denials. If that is the case, you could remove the symlink at ~/snap/firefox/common/Downloads and then mkdir ~/snap/firefox/common/Downloads (again, assuming the access was for ‘Downloads’, adjust as necessary for what you see in journalctl).

This would be a bug in the snap if Mozilla supported disconnecting the home interface. It would be nice if it did IMO; the snap could be fixed if on startup it performed snapctl is-connected home, creating symlinks to ~ dirs if it is, and creating dirs in ~/snap/firefox/common if it isn’t. They’d need to support going back and forth in some manner, which could be replacing empty dirs with symlinks while moving non-empty dirs to the side then creating the symlink. @kenvandine - curious about your thoughts on this?