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.
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.
Virtualization refers to the creation of virtual machines that acts like real computers with an operating system. Software executed on these virtual machines is separated from the underlying hardware resources.
This article discusses LXC, a lightweight virtualization technology built into Linux kernel. The user space LXC tool is distributed with a number of templates that allow the creation of different Linux distro filesystems, usually one template for each major Linux distribution. The problem with these templates is they never work, or they stop working with every new release of LXC tool or of the particular Linux distribution. This is the case with all Linux distributions, and Debian is no exception. Currently, the Debian template is borken under “wheezy”. The relevant Debian bug is here, and history shows that as soon such a bug gets fixed, lxc user space driver changes again and breaks it. It could be worse, in Fedora LXC was broken in Fedora 15 and it was never fixed.
The simple way to handle the problem is to forget all about the template mechanism and roll your own containers. In Debian you can build the container filesystem using the standard debootstrap, or mount read-only the host filesystem, and then use lxc-execute to start a simple bash session inside the container. In this session you can than start all the programs you need to run in the container. It is an application container, very similar to the containers created using the official ssh template distributed with LXC.
The virtual machine I will describe in this article uses a root filesystem build using debootstrap (apt-get install debootstrap). The procedure is simple and it should work on any Debian machine. It will probably work also on any other distro based on Debian, such as Ubuntu, Mint etc.
A live CD or live DVD is a complete bootable Linux operating system loaded from a CD or DVD. Although there are a lots of live Linux CDs, for seemingly every taste and purpose, it might still be useful on occasion to build your own. This guide details the steps to build a bootable live CD/DVD based on Debian “wheezy”.
Step 1 – Installing the necessary software
These are the software packages you need to install on your Debian system:
# apt-get install xorriso live-build syslinux squashfs-tools
Step 2 – Create a basic filesystem
Start by creating a new work directory, and bring in a basic Debian filesystem using debootstrap. Depending on your network connection, it will take some time downloading all the necessary packages:
# mkdir ~/livework && cd ~/livework # debootstrap --arch=amd64 wheezy chroot
The new filesystem was created in ~/livework/chroot directory. It is time to chroot into the new filesystem and finish the installation.
Virtualization allows the creation of multiple virtual machines (VM) on top of an existing computer, each VM configured in a very specific way. All virtual machines run in parallel alongside the regular host applications, without affecting the host system. The type of virtualization I am currently using is Linux containers (LXC), a lightweight virtualization technology built into Linux kernel.
This is my third Debian virtualization article. In the first article, I’ve described the steps to create and run a basic virtual machine using LXC. In the second article I’ve isolated the VM on its own network segment, with its own TCP/IP networking stack. Both articles were dealing with server VMs, I’ve used Lighttpd as an example throughout my articles.
I will describe now how to run desktop applications such as Mozilla Firefox and LibreOffice in a virtual machine. I will use virtenv to build and run the VM. virtenv is a QT4 application released under GPLv2 license. It is basically a configuration wizard that allows you to configure and start the LXC-based virtual machines. Once the VM is started, you get a regular controlling terminal (xterm) and a desktop window running the lightweight Openbox window manager. In this window you can run your GUI applications, very similar to VMware Workstation or Oracle’s VirtualBox.