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
Firejail is a Linux security SUID program that drastically reduces the risk of security breaches by sandboxing the running environment of untrusted applications. Firejail achieves this by using Linux namespaces and seccomp-bpf which allows the attaching of a system call filter to a process and all its descendants, thus reducing the attack surface of the kernel.
With Firejail installed, you can then launch applications from the command line, such that they have a private view of globally-shared kernel resources–such as the network stack. With this addition to your Linux platform, you’ll gain a heightened level of security to an already secure environment.
Firejail is not limited to graphical applications. In fact, Firejail can sandbox servers, GUI tools, and even user login sessions.
Believe it or not, Firejail is incredibly easy to use. I’m going to walk you through the process of installing and using Firejail.
What makes Firejail so special it qualifies for inclusion in our Essential System Tools feature? Above all, it puts users first.
It’s really easy to install and use. More time to spend actually using software. Most people won’t need any custom configuration. There’s a wide range of software which come with sandbox profiles.
The software helps to reduce the risk of security breaches. It’s lightweight and while it uses CPU cycles, the overhead is remarkably low. Firejail sandboxes do not each run their own copy of a full-blown operating system. Instead they operate in a resource-isolated environment created by standard facilities of your system’s existing Linux kernel. As such, despite the high level of protection offered, the overhead of running a Firejail sandbox is extremely low. So your software, including games, run at full steam, unlike a full virtualisation environment.
Firejail is an excellent tool for the security conscious. While it adds a layer of protection, you should use it with other security tools. We use it mainly for web browsing, and to lock down services.
Firejail is a powerful tool which can be use to sandboxing lot of applications. By default Firejail provides profiles for Chrome, Firefox, Telegram and other famous applications. Wireshark is still missing.
We want to limit the interfaces a user can sniff. To be more specific, we want users capture from bridges interfaces only.