4 ms·

Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesyste

Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc. That’s the point of flatpak. But as long as you use X11, there’s one single privilege escalation path left, and that’s the complicated one I described above.

enriquto 6y ago
What if I don't trust the person that sent me the flatpack container itself? A truly secure sandboxing should be a standard OS facility, not tied to a package distribution method. The flatpack/snap model is all wrong. I need to run arbitrary hostile applications in a safe manner, not only those that the developers have decided to distribute in a certain form.
- kuschku 6y ago
  Sure, but the flatpak model is a way to get these advantages for as large a userbase as fast as possible. If you use flatpaks without bind-home under wayland today, you’ve significantly improved your actual security already. Sandboxing arbitrary badly behaving software is just going to use the same APIs as flatpak, so this helps for your use case as well.
wander_homer 6y ago
> Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc. That's just false. Flatpak has the ability to restrict access to such resources, but it's completely up to the author of a Flatpak application if they make use of it. Like my file manager and text editor are Flatpaks fetched from flathub.org and both applications have unrestricted access to my whole home directory by default, including my shell configuration -- even the Chromium Flatpak can do that by default. Edit: I just counted, out of 30 installed Flatpaks from flathub.org 19 have full access to either my whole home directory or the host file system.
- kuschku 6y ago
  That's true, but not really relevant. The point of flatpak is that it can sandbox applications if just the right flag is set, but this sandboxing becomes useless on X11. Long-term, all applications should strive to be properly sandboxed this way
  - wander_homer 6y ago
    > That's true, but not really relevant. Of course it is. Someone who read your comment and didn't question it might now believe that Flatpaks would enforce filesystem sandboxing and prevent, say some game, from accessing their shell configuration or ssh keys. That's false and it's dangerous, because nothing is worse from a security perspective than misinformed users who have a false sense of security. > but this sandboxing becomes useless on X11. That's also false. For example X11 provides mechanisms like the X11 security extensions which prevent clients from accessing each others data through the X11 protocol (like key events or buffer content), which means when I run my color picker or xev in a such an X11 security context they literally stop working outside of their own window. Firejail makes this type of sandboxing easily accessible and it also provides the ability to easily isolate x11 clients with xpra or xephyr. So it's not like it can't be done, it's just that Flatpak doesn't care about it -- which is fine. With dbus you get the same issues, because clients on the same bus aren't isolated from each other. In this instance however Flatpak cared and implemented a dbus proxy to isolate clients from each other without throwing dbus away.
  - enriquto 6y ago
    > all applications should strive to be properly sandboxed this way I agree, but definitely not this way! The sandboxing details must be 100% controlled by the user. The people who distribute the application should have no say whatsoever about their required permissions. That's ultimately for the user to decide. From the point of view of the application, all files are visible, but it may be a mock filesystem with mock resources. Letting the application distributors chose the permissions defeats the whole purpose of the sandboxing.

enriquto 6y ago

What if I don't trust the person that sent me the flatpack container itself? A truly secure sandboxing should be a standard OS facility, not tied to a package distribution method. The flatpack/snap model is all wrong. I need to run arbitrary hostile applications in a safe manner, not only those that the developers have decided to distribute in a certain form.

kuschku 6y ago
Sure, but the flatpak model is a way to get these advantages for as large a userbase as fast as possible. If you use flatpaks without bind-home under wayland today, you’ve significantly improved your actual security already. Sandboxing arbitrary badly behaving software is just going to use the same APIs as flatpak, so this helps for your use case as well.

wander_homer 6y ago

> Flatpak runs applications in what’s nowadays referred to as container: the application can’t see any processes outside the container, can’t access any filesystem except for files you explicitly open with the application, and especially can’t edit your .bashrc. That's just false. Flatpak has the ability to restrict access to such resources, but it's completely up to the author of a Flatpak application if they make use of it. Like my file manager and text editor are Flatpaks fetched from flathub.org and both applications have unrestricted access to my whole home directory by default, including my shell configuration -- even the Chromium Flatpak can do that by default. Edit: I just counted, out of 30 installed Flatpaks from flathub.org 19 have full access to either my whole home directory or the host file system.

kuschku 6y ago
That's true, but not really relevant. The point of flatpak is that it can sandbox applications if just the right flag is set, but this sandboxing becomes useless on X11. Long-term, all applications should strive to be properly sandboxed this way
- wander_homer 6y ago
  > That's true, but not really relevant. Of course it is. Someone who read your comment and didn't question it might now believe that Flatpaks would enforce filesystem sandboxing and prevent, say some game, from accessing their shell configuration or ssh keys. That's false and it's dangerous, because nothing is worse from a security perspective than misinformed users who have a false sense of security. > but this sandboxing becomes useless on X11. That's also false. For example X11 provides mechanisms like the X11 security extensions which prevent clients from accessing each others data through the X11 protocol (like key events or buffer content), which means when I run my color picker or xev in a such an X11 security context they literally stop working outside of their own window. Firejail makes this type of sandboxing easily accessible and it also provides the ability to easily isolate x11 clients with xpra or xephyr. So it's not like it can't be done, it's just that Flatpak doesn't care about it -- which is fine. With dbus you get the same issues, because clients on the same bus aren't isolated from each other. In this instance however Flatpak cared and implemented a dbus proxy to isolate clients from each other without throwing dbus away.
- enriquto 6y ago
  > all applications should strive to be properly sandboxed this way I agree, but definitely not this way! The sandboxing details must be 100% controlled by the user. The people who distribute the application should have no say whatsoever about their required permissions. That's ultimately for the user to decide. From the point of view of the application, all files are visible, but it may be a mock filesystem with mock resources. Letting the application distributors chose the permissions defeats the whole purpose of the sandboxing.