I have been using Firejail for a few years now and absolutely love it. It is now a central part of my setup and workflows. Here are two features I use regularly:
- The "virtual home" specified with --private=/path/to/folder runs the app with the specified folder as a home folder. I use this for all the apps I sandbox to make sure my real home does not get polluted by tens of config files, cache, etc. Removing all traces of an app is now as easy as deleting /path/to/folder; I find this pretty neat to keep my home folder organized (each app gets its own home in ~/.sandboxes/<app name>).
- Starting an app with --private (without any argument) will run it into a temporary/disposable home folder which will be cleaned up when the app is stopped. I use it to run some apps I don't really trust and don't need persistence for (e.g. I start Chrome with this option so that I get a fresh home, hence profile, every time I need it, same for Zoom when I need to join a meeting---not very often).
And of course all the profiles that are built-in to customize the sandboxing to most popular apps is great!
I'm really thankful for the work being done on this project.
> - The "virtual home" specified with --private=/path/to/folder runs the app with the specified folder as a home folder. I use this for all the apps I sandbox to make sure my real home does not get polluted by tens of config files, cache, etc.
I understand firejail does a lot more but FYI, you can do this simply by typing `HOME=/path/to/folder <app>` in your shell.
It looks neat, but I'm not familiar with most of the tools and concepts mentioned on its page, so if I were to use it, I'd mostly do so as a "fire and forget" and then hope it does its thing properly. Looking at the readme, that means I'd run `firecfg --fix-sound`, then `sudo firecfg`, and then after a logout and login never look back at it.
Would you (or anyone else) happen to know if there's any risks for an unknowledgable user like me to do that, e.g. of breaking my system without knowing how to repair it?
I am far from expert in this but I am not sure I would be comfortable automatically configuring all my apps to run through Firejail using firecfg (if only because in case of breakage it would be harder to understand where it is coming from).
In my workflow, I keep things mostly manual and configure each app I want to sandbox explicitly by creating a shortcut (usually I create a "launcher" in /usr/local/bin so that it takes priority over whatever is in /usr/bin). Here is the one I have for Firefox as an example in "/usr/local/bin/firefox":
I really hope that Firejail becomes more popular at least on par with Qubes OS and to make it more popular hopefully someone can make a Linux distribution based on it. It utilizes seccomp-bpf before eBPF is even a thing, and what a smart programming move with virtually no library dependency. As they always say security is as strong as your weakest link.
Talking about programming, the author of Firejail is most probably the same anonymous programmer who wrote RCP100, a little known slick layer 3 switch/router. The RCP100 codes has been touted as the best quality code ever written in C code alongside Redis[1].
Sandboxing needs to happen by default for all applications, without additional work by users. It needs to be an OS- or package manager-level feature. See iOS for example.
This article is quite biased.
Flatpak can be seen as a framework that allows to sandbox apps, but it doesn't enforce it. Some apps can't be sandboxed totally without modifications.
So the take is more Flatpak apps are not systematically sandboxed.
The "sandboxed" icon issue is not even flatpak, but Gnome Software which is NOT flatpak, which makes me doubt about some other parts of this article as well.
My take on Flatpak is that it's still very much work in progress but does go on the right direction. The core issue is that it's not popular enough to be considered as an official way to package software and a lot of it is packaged by Redhat developers or the community. Which means that a package can be easily abandoned, or modifications in the software itself that would allow proper sandboxing are not happening.
One of the technical problems with directory mappings in snaps is that a directory has to exist in order for you to mount to it, and snaps use a read-only filesystem so can't mount to a directory not already pre-created in snaps. However you can connect /home and /media if you connect the relevant permission (but not /root).
It is definitely a source of general frustration, and I think largely because people are still often using it for CLI tools rather than GUI tools which can make use of portals to grant file access permission and/or use an arbitrary path more easily - which is how it works so seamlessly on macOS [and is supported by flatpak/snap for GTK3 at least].
(Disclaimer: I work at Canonical/Ubuntu in the Support organisation. But not directly with/on snaps, this is a user perspective.)
I mean, it looks cool and all, but I'm not quite sure I get it. Let's say I download a GUI application I kinda trust, but not fully. For example streamlink-twitch-gui [1]. It's a crossplatform GUI for Twitch that uses electron.
Let's say the binary downloaded has 2 exploits:
1. It zips all dot files in the user's home and sends them to a server.
2. It send the X clipboard to a server.
Does firejail protect against either attack? If so, how?
For apps like these, I would have a script that creates a new user, copies the app into $newUserHome, starts Xephr [2] a my main user, starts the app as $newUser with DISPLAY=:$xephrDisplay. I'm no security expert, but those 2 issues seem solved that way. Does firejail practically do something similar but with kernel magic?
1. Is solved by most profiles which will only give access to files required by the given app so it would not get access to all content of the home folder. And even better (although not default behavior), is to use --private to isolate each app into its own fake home folder.
I wish there was a tool to sandbox Windows applications; not primarily for security reasons but mostly because of the immense amount of trash left behind all over %APPDATA% and other random disk locations, the registry, etc.
I wish I could start a command line (terminal) that will virtualize the file system in a "workspace" such that any crap that would otherwise pollute my system drive ends up in a neat box on my "work" drive (I know there's a Windows Sandbox thing but that explicitly deletes everything on close, whereas I'd want to go back into that workspace later to continue work on the project).
I think we can achieve this through windows container(not docker, it won't support interactive GUI application), by using process isolation, most api have been implemented in container.dll(see the exported functions table!), but it is undocumented...
There's some demos that using this API
https://github.com/microsoft/BuildXL/blob/master/Public/Src/...
That looks interesting, but ideally it would be something that works with multiple processes. Imagine opening a command prompt, launching vscode from it and doing a yarn/npm/nuget/pip install; this craps thousands of files for various "caches" and unconfigurable "install roots" and so on.
I think a light-weight Docker for Windows would be great for this actually, but even a simple solution that builds on top of container.dll (or similar technology) to virtualize the file system would be very welcome.
There is now a bunch of userland tools that use cgroups: docker, flatpak, systemd, bubblewrap, firejail, …. Unfortunately non of these is really simple to use. For example, `systemd-analyze security` lists 75 different options. I understand that security is inherently complex. But I hope we will get something more approachable at some point.
tl;dr Linux has some kernel features that can be combined to be used as a sandbox. On windows, in contrast, you would have to use a virtualization layer or sys-call interceptor.
Looks interesting but what I don’t understand is if it really is sandboxed, how would a Firefox know that there is another Firefox running and open a tab there (as per the FAQ) instead of a new Firefox in a different sandbox?
The "sandboxing", as I understand it, only applies to the filesystem; processes can still see other processes run in different firejails if they are being run by the same user.
Sure you could see them, after all you can do a ps and see all processes, but shouldn’t the IPC between firejails be forbidden? How is firejail 2 talking to firejail 1?
> shouldn’t the IPC between firejails be forbidden?
I think it depends on what kind of IPC. I'm not familiar enough with the details of how Firefox does it to know how that would interact with firejails.
Neat! I had created an LXC for Steam, but that was way more involved than I would have liked (especially setting up a pulseaudio socket accessible for it).
- The "virtual home" specified with --private=/path/to/folder runs the app with the specified folder as a home folder. I use this for all the apps I sandbox to make sure my real home does not get polluted by tens of config files, cache, etc. Removing all traces of an app is now as easy as deleting /path/to/folder; I find this pretty neat to keep my home folder organized (each app gets its own home in ~/.sandboxes/<app name>).
- Starting an app with --private (without any argument) will run it into a temporary/disposable home folder which will be cleaned up when the app is stopped. I use it to run some apps I don't really trust and don't need persistence for (e.g. I start Chrome with this option so that I get a fresh home, hence profile, every time I need it, same for Zoom when I need to join a meeting---not very often).
And of course all the profiles that are built-in to customize the sandboxing to most popular apps is great!
I'm really thankful for the work being done on this project.