Lead Image © Victor Zastolskiy, 123RF.com

Run applications in a containerized sandbox with Firejail

Locked In

Article from ADMIN 66/2021

By Matthias Wübbeling

Isolate popular applications in flexible, easy-to-set-up, and easy-to-take-down containers with Firejail.

The namespaces available in the Linux kernel enable what is by now commonplace use of containers in virtual runtime environments, such as with the LXC Linux container runtime or Docker. Manual use of these namespaces is, of course, possible but can be very time consuming because of the large number of options. If you want to start your installed applications in their own sandboxes by default, whether to enhance security or create unambiguous rules for individual applications, Firejail [1] is a useful option.

Isolation

Isolating important system resources with processes in their own namespaces has a long history in the operating system world. The chroot operation, for example, has been a way to isolate applications in the kernel as early as 1979 in Unix version 7. The term "isolation" initially refers exclusively to the root filesystem, allowing a different filesystem to be presented to a program (e.g., to prevent unauthorized and unwanted access to important system resources or settings). Isolation is particularly interesting for applications that run under the root account and must not be given root permissions on the host system.

The process that isolation techniques use today to operate containers originated in the early 2000s. Since 2002, in addition to chroot, namespaces have been available to the filesystem in the Linux kernel, which allows different filesystem content to be visible to process groups, the entire root filesystem, or only specific paths. In the course of time, the use of further resources in namespaces was made possible beyond the filesystem. The Linux kernel currently supports eight different namespaces for process isolation resources [2].