Firejail – Sandbox Linux Applications | Hacker News Reader

Firejail – Sandbox Linux Applications

github.com

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.

I do that with Wine: giving each program its own WINEPREFIX. For example, EAC lives under ~/wine/eac. This makes program removal easy as well.

I do this too! Different Netscape versions don,t get along well on the same "system"

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":

firejail --profile=/etc/firejail/firefox.profile --private=~/.sandboxes/firefox/ /usr/bin/firefox --no-remote $@

In terms of risks, are you mostly concerned about security risks? Or breakage?

Thanks. I'm concerned about both, but I suppose I consider breakage to be the biggest risk for something of which I hardly know what it does.

Your approach sounds viable though, so I might look into setting something similar up for myself as well. Thanks for sharing.

> - 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.

Or do this in a wrapper script, for example:

    #!/bin/sh
    export HOME=/path/to/dir
    firefox

I've been using Linux for just under 3 years now and I had no idea this was a thing. I'm amazed at new things I learn every day. Thanks a lot!

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].

[1]https://news.ycombinator.com/item?id=18037775

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 is pretty much what flatpack and snap do.

They also unilaterally decide if and when they will change/update your program which firejail would not.

Oh yeah don't deny that. Was just saying if you wanted a user friendly sandbox experience by default for apps :).

True for snap but not for flatpak

I tried a snap for retroarch, and the inflexibility of the directory mappings turned me off to snaps in general.

Firejail from the above comments seems to handle this quite well with virtual homes.

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.)

My understanding was that this is really not what flatpack does. It could in theory, but in practice it does not: https://flatkill.org/

Have things changed since then?

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.

Neat. On the server, we use bubblewrap, a similar tool (comparison with firejail is in bubblewrap readme)

https://github.com/containers/bubblewrap

Can you go into how you use it on the server? I'm used to software I install running as a non-privileged user; how does bubblewrap help secure things?

I run image processing (imagemagick, vips, etc.) in the sandbox, to reduce security risks with maliciously crafted image uploads.

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]: https://github.com/streamlink/streamlink-twitch-gui

[2]: https://en.wikipedia.org/wiki/Xephyr

I am far from being an expert but I think that:

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.

2. Is also not default but seems to be possible according to official wiki: https://firejail.wordpress.com/documentation-2/x11-guide/

Very interesting! Thank you.

I might start using firejail now.

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).

Historically, thinapp[0] on windows has done this.

I'm not certain if it still can do this, but it used to be able to.

[0]: https://en.wikipedia.org/wiki/VMware_ThinApp

Have you looked at Sandboxie? I'm not sure what the best-maintained version is since it went open-source so I'll just point to Wikipedia

https://en.wikipedia.org/wiki/Sandboxie

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.

All these are great, but the downside is that they are not interactive — you have instead static profiles that specify what is allowed and what not.

In contrast, think of mobile OSes where you are prompted (interactive!) whether to allow an app to access/do X.

I've used Firejail for years and can definitely recommend it! It has a lot of nifty features, e.g. network namespacing via the --net argument.

Is there a performance decrease when running apps in firejail?

I see a mention of x11 support here[0], but how is Wayland support?

[0] https://firejail.wordpress.com/documentation-2/x11-guide/

There isn't a performance decrease. Apps run as an ordinary process but with extra restrictions about what they can access.

How? Usually that would require a layer of virtualization that checks all syscalls to filter out the naughty ones.

They have a sections discussing the technology in their docs.

https://firejail.wordpress.com/documentation-2/basic-usage/#...

https://firejail.wordpress.com/documentation-2/seccomp-guide...

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.

Seccomp does that. No need for a visualisation layer.

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?

> ... after all you can do a ps and see all processes ...

Which you can prevent by mounting /proc with the "hidepid" option.

> 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.

Unless not possible due to requirements of a specific program, firejails have their own PID namespace and can only see themselves.

It is because of user namespaces. I assume you can tell firejail to use seperate ones with some commandline switches.

How much of what freejail provides is already part of snap?

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).

Can this provide application firewall kind of network control, like Little Snitch?

Reply on news.ycombinator.com