We are happy to announce the release of Firejail version 0.9.8. Firejail is a generic Linux namespaces security sandbox, capable of running graphic interface programs as well as server programs. The new release brings in several bugfixes, a number of new security feature, and new monitoring capabilities:
The goal of this article is to isolate a small public web server on a simulated demilitarized zone (DMZ) network, and to restrict the local network access in case the server is breached. It is an extra security layer added to an existing home server setup.
The DMZ consists of an internal network 10.10.20.0/24 connected to br0 bridge device. On this network I place a Linux namespaces security sandbox at 10.10.20.10, running a web server. In case an intruder gets control of the web server, he will be running with low privileges as a generic www-data user. The host firewall configuration will not allow him to open connections anywhere outside DMZ network.
Firejail is a SUID sandbox program that reduces the risk of security breaches by restricting the running environment of untrusted applications using Linux namespaces. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table.
Started as a simple sandbox for Mozilla Firefox, Firejail was expanded to work on any type of executable, such as servers, graphic programs, and even as login shell.
The program is written in C and only needs libc and POSIX threads (libpthreads), available by default on any Linux platform. The download page provides source code (./configure && make && sudo make install), deb (dpkg -i firejail.deb) and rpm (rpm -i firejail.rpm) packages. Once installed, you can start a program in sandbox as:
$ firejail [options] program and arguments Example: $ firejail --debug firefox
To login into a Firejail sandbox, you need to set /usr/bin/firejail as user shell in /etc/passwd. You can change the shell for an existing user with chsh command:
# chsh --shell /usr/bin/firejail
Another option is to define the shell when the user account is created:
# adduser --shell /usr/bin/firejail username
Below is a ssh login session into a sandboxed account:
In part 1 of this article series I’ve described a minimal Debian installation using network install image. I started with a regular server, added the desktop environment, and installed some more common desktop applications. In this article I will continue with several enhancements to the previous setup. Most of the information in these articles applies to other desktop environments as well.
Linux kernel manages all RAM memory in your computer. Unused memory goes into a special buffering pool, where the kernel caches all recently used data. If a process attempts to read a file and the kernel already has the file cached, reading it is as fast as reading RAM.
Filesystem-heavy task, such as compiling source code, processing video files, etc. benefit from as much free memory as possible in buffering pool. It is not uncommon today to see users with powerful systems running tiling window managers in only a few megabytes of memory. Also, with the personal computer market in decline, people tend to keep their computers longer.
I use free command to measure memory. It basically prints out values provided by the kernel. Of interest to us is the number on -/+ buffers/cache line, 121MB in the example below:
The traditional Linux security model starts with file permissions. The model lets the kernel decide whether or not a process may access a resource based on permissions set as part of the filesystem. The coarse-grained granularity of this model often causes Linux processes to have too many rights. If more granularity is needed, one has to resort to adding security related code into the program source.
This series of articles is about Linux namespaces, a lightweight virtualization technology implemented in Linux kernel. In part 1 I’ve talked about building chroot jails using mount namespace, and in part 2 I’ve looked into isolating processes using PID namespace. The next step is to isolate the TCP/IP networking stack using network namespaces.
Security at this level is always reactive. Assuming the bad guy breaks into your server, he will realize he doesn’t have root privileges (classic Unix privilege separation implemented in server software), he runs on top of a fake filesystem (chroot), and he cannot get outside on the network. The later is usually done by placing the computer in a Demilitarized Zone (DMZ) behind a firewall.
The same effect can be achieved on the cheap using Linux namespaces. For this, I place the server in a container (vm1) running its own network segment (10.10.20.0/24). The container is connected to the host through a Linux bridge interface (br0). On the host I configure iptables firewall, isolating the server and effectively limiting the potential damage that could be inflicted on the larger network. The final setup looks like this:
Linux ptrace() system call provides a means by which one process may observe and control the execution of another process. It is primarily used to implement breakpoint debugging with gdb and system call tracing with strace. In this article I will look at the security implications of ptrace, and how to overcome them using Linux PID namespaces.
Public enemy numero uno
This is an experiment every Linux enthusiast should try. Start an ssh connection in a terminal and stop when you are just about to enter the password:
Open another terminal, find the pid of your ssh session (ps ax | grep ssh) and start strace on it (strace -p 3660). Then, go back to your ssh terminal, type in your password, and watch it flying across strace terminal:
Namespace isolation is the simplest virtualization technology available in Linux kernel. It allows a process and all its descendants to have their own private view of the globally shared kernel resources, such as the network stack, process table, mount table. This feature is mostly popularized and promoted by utilities such as LXC (Linux Containers), Docker and virtenv.
Three syscalls are used to create Linux namespaces, unshare(), clone() and setns(). In this article I will take a look at unshare() and show how to use it directly in your scripts and programs without going through LXC or any other higher level virtualization tool.
I’ll start by investigating unshare command available in util-linux package, and from there I’ll move to the system call. In the end I’ll build a small C program that isolates a web browser such as Mozilla Firefox into a kernel namespace.
It might not get the attention Fedora and Ubuntu do, but its parent is still one of the major enterprise Linux distributions. Released on schedule as always, openSUSE is considered by many to be the best KDE distribution, constantly contributing directly to upstream KDE project. A number of other desktops are also supported, I will take a look at some of them in this article.
I’ve installed openSUSE 13.1 using openSUSE Network Installation CD (netinstall). I brought in the desktop environments one by one, reboot the computer, log in, and measure the startup memory for each one of them in a terminal. I left the desktops as they were installed by default, without any modifications.
Measuring memory is easy, Linux kernel keeps track of it all the time. Kernel data is accessed by free command, and printed on the screen. Of interest to us is the value on -/+ buffers/cache line, 121MB in the example below:
Adam Williamson from happyassasin.net has a nice article titled Some comparisons between Fedora 13, 15, 17, 19 and 20. Adam works for Red Hat as Fedora QA Community Manager, meaning he knows what he’s taking about:
We can see that the memory used when you simply boot to a console and log in has changed very little all the way back to Fedora 13, released 2010-05-25. We’re doing a fairly good job of keeping our base system from bloating excessively. 19 and 20 are both 30MB worse than 17, but then, 17 was 25MB better than 15.
The same certainly doesn’t hold true for the graphical desktop, though. Just sitting at a mostly-idle desktop with a terminal open, our memory usage has gone from 275MB under the ancien GNOME 2 regime to 300MB with GNOME 3′s ‘fallback mode’ (which was more or less GNOME 2), then rocketed to nearly 400MB, 535MB, and nearly 700MB in subsequent releases. I haven’t yet looked in detail at the changes, but I did take screenshots of ‘top’ ordered by memory usage for each install.
The measurements are done using free command in a gnome-terminal immediately after bootup. GNOME runs in a virtual machine without hardware acceleration, and it ends up using Mesa llvmpipe driver. These are the graphs based on Adam’s measurements: