You're viewing a single thread.
There's plenty of good advice in other comments in this topic. Let me add mine too, something I haven't seen in other comments: You need to figure out your threat model, and steer your course accordingly.
Who do you trust?
- No one? Don't use a computer. Use an airgapped computer without any internet connection. Write your own OS (but be mindful of bootstrapping issues, you'll also need to write your own compiler to protect against Thompson's hack). It's a hassle.
- Original authors of software? Compile and install all software from source. Consider using LFS. It's a hassle.
- Maintainers of my operating system of choice? Only install packages from official package repositories (apt in Debian, pacman in Arch, you know the drill). Eschew any others, like PPA in Ubuntu, AUR in Arch. Though package maintainers don't necessarily review any package updates, there's a chance they just might. Though package maintainers are in the position to inject backdoors during packaging, this is somewhat unlikely as packaging scripts tend to be small and easy to review.
What risky activities are you doing?
- Running random crap software downloaded from the internet?
- Run it in a virtual machine. It's easy to install another Linux into a VM - you could try VirtualBox or qemu or libvirt or some other one.
- Containerize it with Docker, or run it in Firejail or Bubblewrap
- Don't mount your home directory, or anything other important into the container. Instead, if you need to pass data, use a dedicated directory.
- It's easy to restrict internet access to a program, when running it in Docker or Bubblewrap.
- Running the same as root? I'm pretty sure a full virtual machine would be the only secure option to do that, and I'm 100% certain even that would be enough.
- Running large software that probably ought to be OK, but you never know for certain? This is what I normally do:
- Use the Flatpak version, if available. Check its permissions (e.g. with Flatseal), you might be able to tighten the screws. For example, a browser (yes, Firefox, Thunderbird, Chromium are available as Flatpaks. Even Chrome is) is plenty large enough for any number of security bugs to hide in. Or a backdoor, which might be crafted to be indistinguishable from a honest bug.
- If there's no Flatpak version available, I Bubblewrap it.
I have a simple Bash script that restricts apps' view of my filesystem, and cuts off as much stuff as possible, while retaining the app's ability to run. Works with Wayland and console apps, optionally with Xorg apps if I set a flag. Network access requires its own flag.
I could share my Bubblewrapping script, if there's interest.
Thanks for the helpful list. I had concerns in the past about flatpak, because as far as I know the dependencies are bundled into the flatpak and are not using the latest version of your distro. But that means that some flatpaks probably use outdated and unsecure dependencies.
Whats your opinion on that matter?
I found flatpak to in fact be ahead of distros' packages. Granted, I use distros that are rather conservative on update (Debian, Gentoo, and Linux Mint). If you use something bleeding edge like Arch, things may be different, but shouldn't be far off.
Either way, I find flatpak to be reliable.
Indeed, Flatpak is its own repo. It might be more, or it might be less up to date than your favorite distro. Debian, for instance, was once notorious for packaging ancient versions (tho this has improved lately).
The saving grace of Flatpak is that it's still better isolated.
If native Chrome decides to start emitting your crypto wallet's privkeys as a part of its push for Better Customer Experience and More Precisely Targeted Ads, you won't even know or notice it. This is technically very easy to do. It might make itself hard to dislodge by injecting itself into ~/.bashrc or the desktop environment's startup system, or Systemd services.
If Flatpakked Chrome starts misbehaving, it might mine crypto on your CPU (wasting your electricity), or rent out all your disk space, or turn your PC into a node in a botnet, but it won't have access to read or write anything other than your ~/Downloads. It's also easy to uninstall, as it hasn't had a chance to spread its seed.
Sorry for the long rant... What was the original question again? Outdated dependencies? Not an expert, but I hear the whole reason AppImage, Snap, FlatPak, Yarn locks and Go language was invented was to make it easier to have outdated dependencies. You never know what's available in $Distribution, you depend on goodwill of maintainers of $Distribution to package your app and all deps. In AUR you can find older versions of Lua libs (lua51-filesystem) which someone had to add to make Mudlet run - Mudlet didn't see fit to upgrade to the latest Lua.
While it is indeed somewhat true that a library (that many apps depend on) can be patched to fix a security issue, and apps won't need to be rebuilt, it only works if the lib was a sufficiently recent version. And if the distro maintainer is more diligent than the Flatpak maintainer. Otherwise, the authors of said lib are going to ask you to upgrade to a supported version where that bug has already been fixed, defenestrating the whole argument-in-favor. This completely breaks down in NixOS, too, where your package would get rebuilt from source as inputs changed.
Wow really helpful
do not use browsers from flatpak. browsers have their own built in sandbox that is crippled or sometimes fully disabled in order to make flatpaks sandboxing work, which are often less restrictive than the browser's.
flatpak is better than nothing for the average user but most packages completely ignore the sandboxing it is supposed to use and require manual changes on flatseal.
Interesting, could you please elaborate?
- What exactly is this "built in sandbox", and what does it protect against? How does it compare with Flatpak disallowing access to filesystem?
- Could we get a source for the claim of sandbox being crippled? Or more details? Documentation? Build scripts?
I had a look at flatpaks I have installed:
-
Firefox (org.mozilla.firefox): no access to ~
-
Thunderbird (org.mozilla.Thunderbird): no access to ~
-
Element (im.riot.Riot): no access to ~
-
Beyond All Reason (info.beyondallreason.bar) - no access to ~
-
Steam (com.valvesoftware.Steam) - no access to ~, and (best of all) Steam runs a ton of untrusted code in games, which will inherit this restriction.
-
Wolfenstein: Blade of Agony (com.realm667.Wolfenstein_Blade_of_Agony) - no access to ~
-
Chromium (com.github.Eloston.UngoogledChromium): allows access to ~ by default. It's one click to disable, or I could shop around for another one, like org.chromium.Chromium.
-
OpenTTD (org.openttd.OpenTTD) - allows access to ~
Thus, yeah, some apps neglect to restrrict ~, thankfully it's easy to fix. It's not a disadvantage, though, it's a lack of advantage.
I would actually like to see your Bubblewrap script if you wouldn't mind sharing. I've been thinking about trying to learn how to use it for a while now, but I've kept putting it off since getting Xorg programs to work with it seemed difficult/confusing to me.
Here it comes: https://paste.ee/p/voTFI
Note that I'm no Bash expert, and you'll undoubtedly find ways to improve or fix it. Usage:
- Run stuff in a sandbox
isolate bash- and then verify your access to filesystem is restricted - Enable Xorg for apps that need it
X=1 isolate mindustry- Wayland, which naturally isolates apps from each other, is enabled by default.
- Enable network for apps that need it:
NET=1 isolate curl https://ip6.me/api/ - Enter the sandbox to mess around with it manually:
NAME=mindustry isolate bash- Note that it doesn't catch Ctrl-C. Ctrl-C kills the isolated Bash.
- Populate data (installers and whatnot):
NAME=mygame isolate ls; cp installer.sh ~/.local/share/bubblewrap/mygame/; NAME=mygame isolate bash
- Run stuff in a sandbox