Firejail is a program that can prepare sandboxes to run other programs. This is an efficient way to keep a software isolated from the rest of the system without need of changing its source code, it works for network, graphical or daemons programs.
You may want to sandbox programs you run in order to protect your system for any issue that could happen within the program (security breach, code mistake, unknown errors), like Steam once had a “rm -fr /” issue, using a sandbox that would have partially saved a part of the user directory. Web browsers are major tools nowadays and yet they have access to the whole system and have many security issues discovered and exploited in the wild, running it in a sandbox can reduce the data a hacker could exfiltrate from the computer. Of course, sandboxing comes with an usability tradeoff because if you only allow access to the ~/Downloads/ directory, you need to put files in this directory if you want to upload them, and you can only download files into this directory and then move them later where you really want to keep your files.
For running applications sandboxed in Linux, Firetools is a good utility to do so. Sandboxing is essentially restricting applications in their own space and thereby limiting their reach to the overall system. This is a security layer to prevent any malicious programs to have full access to the system.
Firetools is a graphical front-end for the command-line sandboxing tool Firejail.
Mainly Tor and DNS because that’s what I’ve been doing lately.
Before we start, let’s get into the habit of cleaning up some files when we shut down the computer. For this you need a systemd unit file (see Appendix 1) and a simple script (see Apendix 2). Copy the unit file in
/etc/systemd/system directory, and the script in /etc. The contents of the script is as follows:
rm -fr /home/netblue/.cache
.cache directory is the place where people find copies of all the webpages you visited, torrent trackers you connected to, and all that emails you thought you deleted – all 3 GB of them!
After that, take a look at
/etc/machine-id. This is a world-readable file containing a huge random number:
$ cat /etc/machine-id
Sort of a serial number, it is used to uniquely identify Linux computers. You definitely don’t want it on your home network. But since it is required by systemd, generate a new one on shutdown. Actually, there is another copy of this file in
/var/lib/dbus/machine-id, so you have to deal with both of them:
Security is one of the most important and overlooked aspects of modern computing. We tend to let the default security configurations do the work, or on Windows, we simply install some anti-virus and be done with it. However, applications are increasingly privileged and we find ourselves running programs that could represent a security vulnerability to our systems and, more importantly, to our information.
Sandboxing allows us to limit what each application can see and what it can access, as well as what it can do in your system. Clearly not all applications need sandboxing, for example, your text editor probably isn’t a security vulnerability. Regardless, applications like browsers are the source of many security vulnerabilities, even though they already do some sandboxing themselves.
In this post, we will use a very simple sandboxing method using Firejail and AppArmor on Linux.
If you use Firejail to run Signal Desktop in a sandboxed environment on Linux, you will likely be surprised by the fact that a new application instance is opened every time you execute the firejail signal-desktop command. Attempting to open a second instance of Signal Deskop should simply cause the existing one to be activated instead, but Firejail breaks this default behavior.
On top of that, if you use the –use-tray-icon parameter to have Signal Desktop place an icon on your desktop environment’s icon tray, the icon may not only be displayed incorrectly, but each new opened instance will place an additional (incorrect) icon there as well, making things even worse.
Addressing these issues is fortunately easy. All you need to do is create a Firejail profile file named signal-desktop.profile inside the ~/.config/firejail/ directory containing the following:
This page lists the changes I make to a vanilla install of Arch Linux for security hardening, as well as some other changes I find useful. While Arch is my target platform, most of the changes will work on any Linux system that’s reasonably up to date.
I typically favor security over performance. You may also see suggestions merely to make something more useful or shave precious seconds off a wait time. It’s not a one-size-fits-all setup, but hopefully certain pieces of it will be useful.
I chose Arch for a few reasons:
- The install size: The base install is relatively minimal compared to a “prebuilt” distro like Fedora or Mint. This lets me focus on adding just what I want, rather than constantly trying to strip out things I don’t need.
- The kernel: A common misconception about the Linux kernel is that it’s secure, or that one can go a long time without worrying about kernel security updates. Neither of these are even remotely true. New versions of Linux are released almost every week, often containing security fixes buried among the many other changes. These releases typically don’t make explicit mention of the changes having security implications. As a result, many “stable” or “LTS” distributions don’t know which commits should be backported to their old kernels, or even that something needs backporting at all. If the problem has a public CVE assigned to it, maybe your distro will pick it up. Maybe not. Even if a CVE exists, at least in the case of Ubuntu and Debian especially, users are often left with kernels full of known holes for months at a time. Arch doesn’t play the backporting game, instead opting to provide the newest stable releases shortly after they come out.
- The Arch Build System: Having enjoyed the ports system of FreeBSD and OpenBSD for a long time, the ABS has been a pleasure to use. It makes building/rebuilding packages easy. It makes updating packages easy. It shows how things are actually built and with what options. This BSD-borrowed concept makes interacting with the package system simple and intuitive.
Now on to how I set things up.
Sometimes you may want to use an untrusted application on your system which has not been tested yet. Running this application on your system may lead to a security issue to your system. In this situation you must run this application in a sandbox. So what is a sandbox? Sandbox means to run an application in a limited environment. In this way you can use an untrusted application without taking care of the security of your system.
Firejail is an SUID (Set User ID) program provided by linux which can be used to minimize the security issues of your system while running untrusted applications in a limited environment. Firejail uses the concept of sandbox to minimize security issues. In this blog we will see how to install and use Firejail in Ubuntu.
While Zoom works on Linux, the application is not free software. As a result, some might be wary of running this directly on their computer. One way of running Zoom without worrying about what it does is to use firejail.
To use Zoom with Firejail, first install Zoom or download the archive. Zoom offers standalone binaries that you can download should your distribution not have a package for Zoom. Once installed, install firejail.
Once both firejail and Zoom are installed we need two things:
- A firejail profile for Zoom
- A directory we can use as the home directory for Zoom, preventing it from messing with your home directory