Oh damn. Thanks!
Out all the three containerized formats available, if I do use any of them it will be Flatpak and if that is not available I will use an Appimage.
I have to agree with this now.
But I’m curious to know what is a good way of sandboxing desktop applications then, because I have tried using Firejail in the past and that still takes a lot of time to configure to get your applications working correctly even though the project has profiles available?
Using a VM, or something that works like a VM. Absolute best way in my opinion.
It’s still a desktop app. It’s just running within another desktop that you have even more control over because you can easily stop it from connecting to the internet, or worse your files in case of a virus, malware, backdoor, etc.
Of course, if you are playing a game or using a power-intensive app, then performance can become an issue real quick.
How I always test programs or websites I’m uncertain of to see what they are about if it is dodgy delete the VM and reinstall if not I keep it going and run it on my system. This doesn’t counteract things like the xz exploit but lets you determine pretty quick with a bit of knowledge
I don’t think that’s a realistic solution if all you want to do is sandbox apps like Spotify, Discord, Steam and Lutris. I am looking for a good sandboxing solution, that works within your normal desktop installation, not vm isolution solution.
whenever we see news about a security breach like this, it’s easy to overlook some things:
- exploits happen in all kinds of software from time to time. Nothing is perfect. Just like the recent xz backdoor in core linux packages still doesn’t cancel the fact that linux overall has a strong security advantage due to most malware being created for windows and macos; and linux having a package repository system that is regularly being checked for malware (this kinda eliminates the need to download .exe files from random websites)
- just like the xz issue, this issue has already been fixed (if you updated your system). I think it’s a good sign when the devs take care of it quickly.
- we don’t hear about flatpaks having security issues that often, do we? Again, nothing is perfect, so it’s about finding what’s more secure than the rest, what gets security issues less often. I think flatpak is probably that; although I’m not a security expert and I wouldn’t know for sure.
(I’m sorry if any of this was too obvious to mention)
I agree but it’s never bad to look for ways to improve security and to try and find a good way of isolating applications for increased security even though the current solutions may not be good enough yet.
Flatpak provides some potential advantages and a ton of limitations. That is not to say you shouldn’t use flatpaks - but think carefully about the use case.
The security vulnerability in Flatpak would not deter me form installing applications from Flathub. Yes, it is not good that an app that is supposed to be sandboxed can run code outside of the sanboxed environment. But in order for this vulnerability to actually cause harm, you would first need to install an application that contained malware designed to exploit this vulnerability. Personally, my approach to security involves hinges on not installing untrusted applications in the first place.
The second point I would make is that the sandbox is a compatibility/stability layer, not a security feature. Yes it is true that sandboxing can provide security advantages, but as @Kresimir points out, it can also create and hide vulnerabilities:
There are two advantages to Flatpaks in general which are not really relevant for rolling release distros like Arch:
- Flatpak allows application developers to ship software with the most up to date dependencies (which means that they can in theory work better than native versions on LTS distros like Debian).
- Flatpak also allows developers to ship dependencies which with specific modifications, patches and optimisations for their applications.
I do see a clear advantage in Flatpak’s existence as a baseline standard for desktop Linux that any distribution (other than Ubuntu I suppose) can use. Given the sheer variety in the desktop Linux ecosystem, a baseline standard could be valuable in convincing application developers to release supported versions of their applications for Linux. If there is a choice between my chosen application not existing on Linux or being available only as a Flatpak, it is obvious which one is better.
However, if my chosen application is available both as a Flatpak and on the Arch Repo/AUR, I will obviously choose the version on the Arch Repo/AUR. The meme that “X is bloat” is unfortunately true in the case of Flatpaks, though whether or not this matters depends on the use case. Last year, for example, I installed the Steam Flatpak because the native version was throwing up weird errors. For context, my laptop has a 250 GB SSD with 50 GB allocated to my root partition, 8GB allocated to swap and the balance allocated to my /home partition (I also have a 1TB HDD which is mounted under /home for file storage, but that is not relevant). I chose this configuration on assumption that user-level applications like Steam can access system libraries. Being forced to partially reinstall some of my system libraries in the /home partition just to use a single Flatpak app resulted in my /home partition running out of space while the my root partition still had an extra 15-20 GB of space remaining. This experience taught me two things:
- Flatpaks are bloat
- When the time comes to replace this four year old laptop, I should invest in a bigger SSD drive.
Because the way linux package managers such as pacman normally install packages is superior, plain and simple, I come from a windows background (although by this point i suppose i’m more of a linux gy than a windows one, but i’ve still spent more years combined on windows than linux) when I first used linux package managers confused me, but by now when I actually understand what it’s doing anad why it is the way it is, it’s blatantly obvious to me that it is superior, and for the occasional edge cases where it might not always be superior, we have workarounds (like steam-runtime if native libs aren’t working right with some game; which even then almost never happens).
AUR is slow for you because you are often compiling the packages from there, if you download packages marked as -bin you get them precompiled and it should be about as fast as any package manager.
Appimages and Flatpaks are a rough imitation of how applications are installed and distributed on windows. the thing is though, if you have an official repo or aur version of a package you are almost always better off using that over flatpaks or appimages because of some of the quirks and eccentricities of flatpaks and appimages (not to mention duplicate libraries, if you use a lot of them you’ll be sacrificing some storage space compared to official packages), personally what I hate most
about the things is that they can’t just use the normal .config .local and .cache paths of the apps, they have some super weird naming schemes that pointlessly complicate any application you install with them.
There’s also a security concern, i would much rather use an easily auditable pkgbuild than an unofficial appimage or flatpak where I cannot discern how it was created or who it was created by, it might be ok if there is an official flatpak or appimage made by the software’s developer, but otherwise I would avoid it like the plague.
The only thing flatpak and appimages are good for, are distros that do not have AUR (So basically non-arch distros) because for them, installing packages that aren’t officially supported can be a royal pain in the buttcheeks. But well, I prefer AUR, so here I am.
I have only once tried to use flatpak or appimages, forgot which one it was, it was to install something like pulseeffects or easyeffects. It didn’t work, so I went back to the official packages, and they worked. That told me everything i needed to know about these bloody things.
You have to start with a question. “What am I trying to sandbox the application from?”
If the answer is everything, then use a VM and isolate it’s network from your internal network.
If you want to really isolate - not just VM…but Whonix VM.
Trust level: source code > official repo > AUR > appimage > random shady developer met at an unspecified train station at night > flatpak > everything else
My reason for wanting to sandbox is just to isolate the few proprietary applications that I do use including the games, since CVE’s for game’s don’t seem to get published. So that if some weird vulnerability is in a game that isn’t fixed it would confine that to the sandbox and not effect the rest of my pc, that was my thinking behind it.
The problem is that sandboxing isn’t an on or off proposition. For example, you probably don’t want your application to fully sandboxed. If it was, you wouldn’t be able to interact with it. Any application running directly on your system has some access to your system. So then you need to start thinking about what specific things do you want to block and allow which is why firejail takes time and work to properly configure.
Yeah I found that out with Firejail. I had everything working except I ran into trouble with one game, in the end I got tired of that game because it wasn’t really my type of game. So I could set it up again this time because I saved all my include files with customization.
Personally I feel no dislike for flatpak, just see it a as an optional packaging app format, the only time I have felt the need of it was last year with spotify and jamesdsp equalizer flatpak packages, all went well but I am not running them in my workflow this year. In my opinion I am a fully ignorant sandboxing user and have never considered flatpaks cons when I installed in my system so far. AUR packages can also be unreliable sometimes when you install some unmaintained ones or with slow frequency of revisions. But if you are running some linux distro self-safe and contained type like Debian or KaOs, Flatpak and other packaging choices become a valid option to achieve your everyday workflow system as you like it to be. I am actually paying my attention to Nixos packages (more than 100.000 packages) suggested by Matthias Schuster (FB KDE admin and also KaOs Forum member) as a way to “solve the KaOs package shortage” post. He provides an interesting option to add Nix package manager into KDE plasma KaOs. https://forum.kaosx.us/d/3145-solving-the-kaos-package-shortage
Applications built inside Flatpak aren’t statically linked.
Yes, they ship dependencies separate from the system installed packages; regardless, the linking is dynamic unless the application was specifically compiled to have static linking. Eg. Electron applications hog a lot of space on Flatpak due to static linking. But the way most Electron apps are distributed (i.e. web runtime included with app), they’ll hog space even on native packaging format.
As for the space taken, Flatpak is based off os-tree, which supports file de-duplication. Even if multiple applications link to the same library, the library will be stored only once on your storage.
Storing applications in a local OSTree repository has other advantages. For example, it allows files that are stored on disk to be deduplicated, so the same file that belongs to multiple applications (or runtimes) is only stored once.
from https://docs.flatpak.org/en/latest/under-the-hood.html
There is indeed a storage overhead because its not using system libraries, but the fear of storing Flatpak libraries multiple times is unfounded.
Another side effect of using os-tree is that Flatpak can support delta updates. It will only download the files that were changed in an update.
The downside? Flatpak’s “runtime” will force you to download unnecessary dependencies. So, if you were to install kcalc for example, it’ll download the complete KDE runtime. So if you use a very limited number of Flatpaks, chances are there’s barely any files being shared and you see high storage usage.
I don’t use Flatpaks on my main system and never suggest anyone to do it either. There are design flaws with it, but the fact remains that Flatpak doesn’t enforce static linking and it supports deduplication.
Legitimate concern. I’ll add that the build scripts for Flatpak applications are public on their GitHub. Eg, here’s one of the Flatpaks I added for KDE: https://github.com/flathub/org.kde.Ikona/ These can be cloned and built similar to how AUR packages can be built.
Again, I don’t suggest people to use Flatpaks unless they really want to. I run Flatpak builder inside a VM which is used for the sole purpose of testing build scripts. I’ll never run Flatpak on my primary machines.
I know, but it does protect your host system.
I’m not entirely sure, but doesn’t Distrobox do this? — Or is it some other solution I can’t remember the name of? Maybe Podman?
Thanks for the reply. Podman is more for running server applications not gui applications. I’ve never heard of Distrobox but will have a look and I may give Firejail another try since I had that setup before.