Complete tutorial on sandboxing in Linux with Firejail and more

Secure your applications on Linux It has become almost mandatory if you browse websites full of aggressive advertising, run untrusted binaries, or manage services exposed to the internet. Although Linux is already a fairly robust system, the reality is that your browser, media players, or any network client can be the perfect entry point for malware, cryptojacking, or data theft if you don't properly isolate them.

In this complete tutorial on Sandboxing in Linux with tools like Firejail, Bubblewrap, AppArmor and kernel technologies You'll see how process isolation really works, what security mechanisms the system uses (namespaces, seccomp-BPF, chroot, resource limits, etc.), and how you can practically combine them to minimize the impact of a potential exploit. The goal is for you to leave here with a clear understanding, ready-to-use examples, and a solid foundation for improving the security of your desktop and server applications.

What is a sandbox in Linux and why should you use it?

When we talk about sandboxing in Linux, we are referring to run programs within a restricted environment, separated from the rest of the system, so that if something goes wrong (exploit, malware, malicious script on a website, etc.) the damage is confined within that "sandbox" and cannot easily affect the rest of the operating system, your documents, or other services.

This approach is especially useful for highly exposed applicationssuch as web browsers, email clients, messaging applications, torrent programs, media players, or network services accessible from the internet. In all these cases, the risk of them processing untrusted content is extremely high, so it makes sense to surround them with several layers of protection.

In Linux, modern sandboxing is based primarily on native kernel mechanisms: Linux namespacesAccess control policies (MACs) such as AppArmor or SELinux, seccomp-BPF filters, restrictions with setrlimit, chroot, and execution under unprivileged users. Tools like Firejail, Bubblewrap, Flatpak, or even container systems like Docker rely on these basic building blocks.

It is also important to understand that Memory safety and sandboxing are distinct but complementary concepts.A program can be written in a memory-safe language (or protected by a runtime that prevents typical C/C++ errors), but if it has full access to the file system and all system calls, it remains dangerous if compromised. Conversely, a program isolated in a sandbox can contain memory vulnerabilities that can be exploited from within. True security comes from combining both approaches.

Firejail: the most popular sandbox for desktop applications

Firejail is probably the the most well-known sandboxing tool on the Linux desktopIt is programmed in C and works as a SUID-bit executable that relies on namespaces, seccomp-BPF and other kernel features to create an isolated environment around the program you want to run.

Its great advantage is that It is very lightweight and easy to useThe speed of applications within the sandbox is almost identical to normal execution; it doesn't add resident processes when the system starts and has very few dependencies. In practice, it only consumes resources when you launch an application through it, making it suitable even for modest machines.

In addition, Firejail comes with Predefined configuration profiles for more than 300-1000 common applications (depending on the version you're looking at): browsers like Firefox and Chromium, VLC, Transmission, PDF readers, text editors, and many more. These profiles specify which parts of the file system each program sees, what permissions it has, whether it can use sound, what kind of network access it has, etc.

You can also use Firejail for server programs and terminal toolsFor example, to jail an Apache web server or a custom service that listens on a specific port. The model is always the same: the process runs within a set of namespaces and restrictions that limit the impact of a security breach.

How Firejail works on a technical level

In order for Firejail to lift its cages, it makes intensive use of Linux namespacesThis functionality, which began to arrive in the kernel in version 2.6.23, has been expanded to offer various types of isolation: PID, network, user, mount, UTS (hostname), IPC, etc. Each namespace encapsulates a set of resources, so that processes that share a namespace see a different reality from those outside of it.

In other words, a program started with Firejail It does not see the same file system, process table, network stack, or hostname rather than the rest of the system, but a filtered or partially assembled version depending on the profile in use. This is the basis of many container technologies, such as Docker, and is the main reason why it is so efficient.

Firejail complements namespaces with access control (MAC) policies on the file systemWith these rules, you can, for example, allow the program to access only specific subdirectories of your home directory, such as Downloads or the application's specific configuration folder, while blocking access to the rest. Many default profiles already include well-defined rules that allow the program to function without letting it freely roam your disk.

Another important layer is seccomp-BPFThis mechanism allows a system call (syscall) filter to be associated with a process. The filter is described using BPF (Berkeley Packet Filter) and defines which syscalls are allowed and with what parameters; any other call causes the kernel to terminate the process or return an error. Browsers like Chrome and container systems like Docker also leverage this technique to limit what running code can do.

Finally, Firejail can living with AppArmor and SELinuxThese MAC systems work at the kernel level to restrict access to files, sockets, capabilities, etc. Firejail adds another layer of isolation: it not only decides which resources an application can access, but also separates it into namespaces so that even several applications with similar permissions don't necessarily have to see or manipulate each other.

Install Firejail and its graphical interface Firetools

In most GNU/Linux distributions, Firejail It doesn't come pre-installed, but it's available in the official repositories.In Debian, Ubuntu and derivatives, simply use APT to incorporate it into the system without any extra dependencies or additional background services.

To install the base Firejail package, you can run:

sudo apt-get install firejail

With that single command you will have Everything you need to use Firejail from the terminalThere's no need to touch configuration files to get started; by knowing a couple of basic commands, you can already jail your first applications.

If you want a more user-friendly graphical interface To launch and configure applications, you can also install Firetools, which acts as a launcher with an icon in the system tray and a setup wizard.

sudo apt-get install firetools

After installation, you'll see two new entries in the applications menu: one for the tray with the launchers and another for the Firejail Configuration Wizard, a step-by-step wizard that lets you choose the application, decide whether to use the default profile or a custom one, and adjust permissions on directories, sound, network, and other kernel protections.

Using Firejail from the terminal: the basics and more

The most typical use of Firejail is to add the firejail command to the executable that you want to isolate. If the program has a predefined profile, it will be applied automatically; otherwise, a generic configuration will be used plus any you add via the command line.

For example, to open Firefox inside a sandbox, the command would be:

firejail firefox

Keep in mind that in distributions like Ubuntu 22.04 and later, Firefox usually comes as a Snap package, so This command may not work directlyIn that case, you'll need to use the APT-packaged version or adapt the profile to the correct path of the binary that actually runs.

The story is similar with other desktop applications. Some common examples would be:

firejail gedit
firejail evince
firejail vlc
firejail transmission-gtk

While those applications are open, if you look at the resource monitor you will see that each process appears as a child of a firejail processTo see the complete tree of processes running within sandboxes at any given time, you can use:

firejail --tree

If you want to explore all the supported options (there are many for networking, X11, bandwidth, custom profiles, etc.), you have the usual option available:

firejail --help

Firejail configuration profiles: where they are and how to access them

The true power of Firejail comes from its configuration profilesEach profile describes how a specific program should be isolated: which directories it mounts as read-only or read-write, whether it has access to the user folder, whether 3D acceleration is allowed, whether it can access the Internet, which DNS it uses, whether it listens to the sound server, etc.

The system's global profiles are typically stored in /etc/firejail/To see the full list available on your machine, you can run:

ls /etc/firejail/

Each file with extension .profile defines the rules for a program. If you want to modify, for example, the default Firefox profile, you can edit it with your favorite text editor by running it with administrator privileges:

sudo nano /etc/firejail/firefox.profile

Inside you'll find Firejail directives that control special assemblies, access, capacities and optionsTo understand all available parameters, it is highly recommended to review the specific manual page for profiles:

man 5 firejail-profile

In addition to modifying existing profiles, you can Create new profiles for programs that do not have their own.In these cases, Firejail typically uses a more permissive generic configuration. If you want to customize the behavior of a specific application, you can define a profile file with its name and adapt it to your needs, using the official documentation and examples from other users.

User profiles: overwriting and extending standard settings

Often it's not in our interest to touch the system profiles in /etc/firejailWhether to facilitate future updates or because you want to have your own variations for a specific user, Firejail supports profiles in the user's configuration directory, which can include the global profile and add or modify rules.

The first step is to create the folder where these user profiles will be stored:

mkdir -p ~/.config/firejail/

Imagine you want VLC never have access to the Internet When you open it with Firejail, you can create a local profile called vlc.profile that includes the global profile and adds the network restriction. To do this, open the file:

nano ~/.config/firejail/vlc.profile

And put something like the following:

include /etc/firejail/vlc.profile
net none

Directive includes Drag the default VLC settings, and the following line adds the rule to block the network. From that point on, launch Firejail VLC It will also use this user file and, therefore, VLC will not be able to access the Internet, remaining limited to playing local content.

Remember that the file name in your user folder must match the standard profile name so that Firejail can detect and combine it properly.

Firejail advanced options: network, private mode, and resources

In addition to profiles, Firejail offers a good arsenal of command line parameters to temporarily adjust the sandbox behavior on each run, without needing to touch configuration files.

For example, you can disable network access for a specific application using the –net=none option. To start VLC in isolated internet mode, simply:

firejail --net=none vlc

Another very powerful feature is the private modeIn this mode, the program runs in a temporary file system (tmpfs), doesn't see your actual settings or personal files, and everything it does disappears when you log out of the sandbox. It's ideal for sensitive operations, such as accessing online banking, testing suspicious websites, or running software that you don't want to leave a trace.

A practical example would be opening Google Chrome with private mode and specific DNS (for example, those from Google):

firejail --private --dns=8.8.8.8 --dns=8.8.4.4 google-chrome

In this scenario, Chrome starts with its default settings, without extensions or browsing history, isolates itself in a tmpfs environment, and uses the specified DNS servers. This is a fairly reasonable way to minimize risks when visiting sensitive websites.

Firejail also allows that Applications within the sandbox use their own virtual network interfacewith a separate internal IP address, ARP table, separate firewall, etc., using macvlan. You could, for example, start Firefox on the eth0 interface with:

firejail --net=eth0 firefox

If you want to assign a specific IP address to that sandbox:

firejail --net=eth0 --ip=192.168.1.80 firefox

Keep in mind that This functionality is currently usually limited to wired networksand may not work on wireless interfaces depending on your system configuration and distribution.

Bandwidth control and sandbox monitoring

A lesser-known feature of Firejail is its ability to limit bandwidth of the applications you run within the sandbox. This is perfect for performance testing, simulating slow connections, or simply preventing a torrent client from hogging your entire bandwidth.

The usual pattern consists of assign a name to the sandbox and then operate on it from another terminal. For example, starting Firefox in a sandbox called browser connected to eth0:

firejail --name=navegador --net=eth0 firefox

In another terminal, you can set upload and download limits with the –bandwidth option, specifying the sandbox name, interface, and values ​​(in KB/s):

firejail --bandwidth=navegador set eth0 80 20

With those parameters, Firefox would be restricted to 80 KB/s download and 20 KB/s upload speeds.If you later want to remove those restrictions, you can clear the bandwidth rules with:

firejail --bandwidth=navegador clear eth0

To know at any time What applications do you have running inside Firejail?The `-list` command displays a list of PIDs, users, and associated programs:

firejail --list

And if what interests you is view resource consumption (memory, CPU, number of processes) of each active sandbox, you have at your disposal:

firejail --top

Enter an existing sandbox and use Firejail by default

There are situations in which you might be interested accessing “from within” a running sandboxFor example, to inspect your network configuration, review mounted routes, or perform administrative tasks. Firejail allows you to join a specific sandbox using the `--join` option, using the PID of one of the processes.

If, for example, at the exit of firejail –list You see that Firefox has PID 5394, you could enter its sandbox with:

sudo firejail --join=5394

Firejail itself takes care of switching to the first child process inside the jail and leaves you in a root shell within that isolated environment, from where you can run the checks you need.

Another very practical possibility is Make Firejail the default way to start any program with an available profileTo do this, you can use the firecfg command, which creates symbolic links in /usr/local/bin pointing to /usr/bin/firejail for each application with a profile.

sudo firecfg

From this point on, every time you launch a program from the list (from the graphical menu or the terminal), it will automatically start in a sandbox. If you ever want to revert this, simply remove the symbolic links created in / usr / local / bin.

If you prefer to apply this behavior to only one specific applicationYou can create the symbolic link yourself. For example, to make Firefox always use Firejail:

sudo ln -s /usr/bin/firejail /usr/local/bin/firefox

When you want to stop using Firejail automatically for that program, you just need to delete the corresponding symbolic link in /usr/local/bin.

Alternative graphics servers: Xpra and Xephyr with Firejail

One of the classic criticisms of the X11 model is that It does not offer good isolation between graphics applicationsThis leaves the door open to keyloggers, screenshots, and other window-to-window spying techniques. Firejail attempts to mitigate some of this problem by allowing applications to run on alternative graphics servers.

In particular, you can use Xpra and Xephyr as separate X servers, so that the jailed program doesn't share the same X server as the rest of the desktop. First, you need to install the corresponding packages on your system:

sudo apt-get install xpra xserver-xephyr

Then, you can launch an application by specifying the X server to use with the –x11 option. For example, to start VLC without network access and using Xephyr:

firejail --x11=xephyr --net=none vlc

If you prefer the application to run on Xpra, the command would be similar, changing the parameter:

firejail --x11=xpra --net=none vlc

With this scheme, You make life much more difficult for keyloggers and screen capture users. that they try to spy on what you do in that specific application, since it remains "connected" to its own graphical server, independent of the rest of the desktop.

Other sandboxing approaches in Linux: Bubblewrap, Flatpak, AppArmor, and containers

Although Firejail is very convenient for the desktop user, there are more tools in the Linux ecosystem geared towards isolate processes and applicationsNone are perfect and all have their pros and cons, but it's worth knowing them to choose the best one in each case.

Bubblewrap is an alternative that focuses on offer a minimalist sandboxing runtimeBubblewrap is cleaner and has a smaller attack surface than a large setuid tool. It's more difficult to configure directly than Firejail, but many modern solutions use it under the hood. Unlike Firejail, Bubblewrap's philosophy is to avoid using SUID whenever possible, reducing the impact of potential internal vulnerabilities.

Projects like Bubblewrap are built on top of it. Bubble Jailwhose objective is to offer a somewhat more user-friendly experience by trying to correct some of Firejail's organizational shortcomings (more consistent profiles, clearer configuration, etc.). The drawback is that it's a little-known tool with a small developer base, so It's not as audited or battle-tested as well as other more popular options.

On the other side is FlatpakIt is widely used to distribute isolated desktop applications. Although it relies on sandboxing techniques (namespaces, portals, declarative permissions, etc.), many experts point out that It's not trivial to configure it without leaving gapsFurthermore, it only applies to applications packaged as Flatpak, so if your program doesn't exist in that format, it won't work for you.

In the field of MAC policies, AppArmor and SELinux They allow you to define very fine rules about which files, sockets, capacities, and resources each program can use. Theoretically, they are very powerful and usually offer a higher level of security than user-defined solutions, but they suffer from the same problem: Setting them up properly is complexCreating robust profiles for each service requires time, experience, and constant maintenance.

In cloud and Kubernetes environments, a very interesting alternative are the containers based on lightweight virtual machines, such as Kata Containers, which Red Hat OpenShift integrates as an optional OCI-compliant runtime. In this model, each workload runs on its own isolated kernel within a lightweight VM, providing a extra layer of insulation above the usual separation by namespaces. An operator is responsible for installing, managing, and updating this runtime within the cluster.

Memory safety + sandboxing: the Fil-C approach and the OpenSSH case

Beyond the desktop, many critical applications run on servers (such as OpenSSH or components of SaaS platforms) benefit from combining memory security and deep sandboxingThis is where the approach of projects like Fil-C comes into play, proposing a secure implementation for C/C++ capable of coexisting well with the native mechanisms of Linux.

OpenSSH on Linux already uses several isolation techniques: chroot (create a chroot cage) to limit the view of the file system, execution of processes as unprivileged users and groups, use of setrlimit to restrict resources (opening files, creating processes, etc.) and filters seccomp-BPF that only allow a controlled subset of system calls; everything else causes the process to terminate.

The challenge for runtimes like Fil-C is adapt to those restrictions without breaking the programFor example, if the garbage collector needs background threads, you must ensure that all those threads are created before activating the sandbox, and that the seccomp filters are installed on all of them, not just the main thread, also respecting settings such as PR_SET_NO_NEW_PRIVS and PR_SET_SECCOMP.

Fil-C offers features such as zlock_runtime_threads()These measures force the initialization of all necessary threads before activating the sandbox and block the creation of new threads afterward, ensuring that restrictions are applied consistently throughout the process. It also requires minor exceptions in seccomp filters, such as enabling MAP_NORESERVE in mmap or the sched_yield syscall, which are necessary for internal runtime management.

This type of work demonstrates that It is possible to combine memory-safe environments, strict sandboxes, and high-profile applications like OpenSSH without sacrificing compatibility or performance. Chrome and Mozilla developers have been documenting similar practices for their own Linux sandboxes for years, setting the standard for robust defense in depth.

Practical use cases: protecting your browsing and your daily life

All of this translates into very everyday scenarios for any Linux user. For example, when you visit Torrent sites, download sites full of pop-ups, porn websites, or portals with suspicious linksThe probability of encountering cryptojacking scripts, malicious ads, or fingerprinting attempts is more than reasonable.

A simple measure consists of jail the browser with Firejail every time you get into those messes. Launch the browser with:

firejail chromium &

O well:

firejail firefox &

It gives you an extra layer of peace of mind. The ampersand (&) at the end is useful for keeping the browser open even if you accidentally close the terminal. If you combine this with solutions like Pi-hole on your local network, or script and mining blocking extensions, You greatly reduce the attack surface. when browsing dubious websites.

Firejail's private mode, profiles that block access to sensitive folders, and the use of controlled DNS for the browser you use with your online banking are small decisions that, added together, They make the difference between a serious scare and a simple closed eyelash..

Looking at the big picture, it's clear that sandboxing in Linux isn't a silver bullet, but it is an incredibly powerful tool if you know how to combine it: Firejail and its profiles for everyday use, Bubblewrap and Flatpak for more controlled environments, AppArmor/SELinux and seccomp-BPF for critical services, and technologies like Kata Containers or memory-safe runtimes like Fil-C when building more complex infrastructures. Ultimately, it's about building layers so that even if one fails, The rest will continue to keep your system reasonably safe.