Flatpak sandbox hole coverage

[danirabbit]

We're now starting to warn about sandbox holes in AppCenter, but there's a ton of different holes developers can poke and turning that into useful information is hard. I'm compiling here a list of different sandbox holes I've seen so we can discuss what they are, how to warn about them if we need to, etc:

--device=all' # Seemingly needed audio devices
--env=DCONF_USER_CONFIG_DIR=.config/dconf",
--filesystem=~/.config/dconf:ro",
--filesystem=/etc:ro
--filesystem=~/.local/share/applications"
--filesystem=~/.local/share/applications:ro
--filesystem=~/.local/share/flatpak/exports/share/applications:ro
--filesystem=~/.local/share/flatpak/exports/share/icons:ro
--filesystem=/run/docker.sock'
--filesystem=/run/podman/podman.sock'
--filesystem=~/.ssh/:ro"
--filesystem=/tmp
--filesystem=/var/lib/flatpak/app:ro'
--filesystem=/var/lib/flatpak/exports/share/applications:ro
--filesystem=/var/lib/flatpak/exports/share/icons:ro
--filesystem=/var/lib/flatpak/exports/share:ro
--filesystem=/var/lib/lightdm-data:rw",
--filesystem=/var/lib/snapd/desktop:ro
--filesystem=xdg-data/applications:create",
--filesystem=xdg-data/flatpak/app:ro
--filesystem=xdg-data/flatpak/exports/share/applications:ro
--filesystem=xdg-data/flatpak/exports/share/icons:ro
--filesystem=xdg-data:ro
--filesystem=xdg-download'
--filesystem=xdg-download'
--filesystem=xdg-run/dconf",
--filesystem=xdg-run/docker.sock'
--filesystem=xdg-run/gvfsd"
--filesystem=xdg-run/pipewire-0'
--filesystem=xdg-run/podman/podman.sock'
--socket=cups"
--socket=pulseaudio'
--socket=ssh-auth"
--socket=x11'
--system-talk-name=org.freedesktop.Accounts",
--system-talk-name=org.freedesktop.Avahi'
--system-talk-name=org.freedesktop.login1'
--system-talk-name=org.freedesktop.NetworkManager'
--talk-name=com.canonical.Unity.LauncherEntry'
--talk-name=org.elementary.Contractor",
--talk-name=org.gnome.OnlineAccounts'
--talk-name=org.gtk.vfs",

• --talk-name=org.freedesktop.FileManager1 is referenced by a few apps for opening Files with a specific file selected
• --talk-name=org.gnome.SettingsDaemon.MediaKeys" shouldn't be accessed directly since MPRIS covers mediakeys. Not sure if there's undesired implications of being able to access this, like being able to control media playback of other apps?
• --talk-name=org.freedesktop.ScreenSaver' I think apps are touching this instead of using the inhibit portal which is built into Gtk.Application. The implication here is that apps can prevent the computer from sleeping or force it to sleep without asking.
• --talk-name=org.gnome.Shell.Screenshot' shouldn't be accessed directly because there's a screenshot portal. This means apps can take screenshots at any time. I think with access to X11 that is true regardless, so not sure if it's worth warning about this right now
• --talk-name=org.freedesktop.secrets Not sure if there's a legit use for this, but it's the keychain. I think libsecret should be able to create its own internal keychain, so this I think means apps can just access passwords for the host which is bad
• --system-talk-name=io.elementary.pantheon.AccountsService", Not sure if this should be combined with the System Settings flag or needs its own warning
• --share=network' should we even warn about apps accessing the internet? Is that valuable information or just kind of assumed to be an okay thing to do?
• --filesystem=xdg-run I think we should blanket warn about accessing this at all and not try to anticipate what people could be accessing here

[danirabbit]

I wonder if there's any legitimate reason to access anything on system-talk and maybe we should just have a blanket warning here?

[Marukesu]

i would say yes? an disk management utility would like to have access to UDisks, for example.

[TingPing]

I just want to reiterate a bit that it is really challenging to actually say any Elementary flatpak is safe. I don't like that but I believe it to be true.

• x11: This is a total sandbox escape, there is no way around this fact. Via X11 you can capture all keyboard input, you can capture all rendered frames of every application you ever run, you can inject arbitrary inputs into any window including running commands in a terminal window or simulating key and button presses.
• Pulseaudio: The application can listen to everything you say (sans a physical mute switch) and everything you listen to.
• Network: Flatpak doesn't filter network access in any way. It can talk to your router, your smart-fridge, your tablet, the local file share service on your machine. Etc.

Filesystem access is also always more scary than you think. I will say a lot of the list you posted is simply a packaging error.

--filesystem=/usr/share/applications:ro
--filesystem=/usr/share/icons:ro
--filesystem=/usr/share/pixmaps:ro

These literally do nothing.

--filesystem=xdg-run/dconf",
--env=DCONF_USER_CONFIG_DIR=.config/dconf",
--filesystem=~/.config/dconf:ro",

This is a legacy workaround to remove.

--filesystem=~/.local/share/icons:ro

Flatpak mounts these icons by default.

--filesystem=/tmp

Likely a legacy workaround no longer needed.

--

Most of the DBus ones are indeed things that should be removed and apps should use the portal.

--talk-name=org.freedesktop.secrets

There is a "portal" for secrets however it only supports a subset of libsecret usage. But this permission does leak all keys from the host.

[danirabbit]

Yup just dumping data here to sort through. For clarity these are AppCenter flatpaks not elementary flatpaks :) So these are third party developer flatpaks.

But yeah I mean ultimately X11 is insecure but there's utility i think between "Theoretically insecure" and like "actively insecure"

[TingPing]

Exploiting GPU drivers, theoretically insecure. Using X11 APIs as they were meant to be used, actively insecure. IMO.

[danirabbit]

Haha I get what you're saying. My point is though that while, yes anything running on X11 is insecure by definition, I think there's still value in pointing out apps that are intentionally punching dangerous additional sandbox holes and probably actively doing things that people don't want them to do, rather than just saying "Everything is insecure". People still want to install and use apps, so we have to work within the constraints of the imperfect world we currently live in. And we won't live in an X11 world forever, so we'll want to do this work anyways since it'll be useful in a Wayland world