2025-12-05 12:38:00

Enhancing x11 Application Security with LXC

Wouldn't it be nice to add an extra layer of security to a web browser or an Electron-based IM application? After all, if a browser is compromised, the entire contents of the user’s home directory may be at risk.

Let’s mitigate this by using LXC to fully isolate the application from the host system.

The system used in this example is Arch Linux, but the procedure should be easily adaptable to other distributions.

The Networking Capabilities

First, we need to install and preconfigure LXC. Install the following packages:

# pacman -S lxc lxcfs

Next, we must provide our LXC containers with networking capabilities. To do that, edit the /etc/default/lxc file and append the following line at the bottom:

USE_LXC_BRIDGE="true"

Now we can start the LXC bridge interface. Enable and start the corresponding systemd unit:

# systemctl enable lxc-net.service --now

A new interface named lxcbr0 should now be available. Verify this with:

# ip a show dev lxcbr0

Creating The Container

With the previous steps completed, we can create our first application container. Let's start by creating an initial configuration.

Navigate to /etc/lxc and create a new configuration file. Since I’m creating a web-browser container, I’ll name mine www.conf.

Open the file with your preferred editor and add the following lines:

lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.hwaddr = 10:66:6a:xx:xx:xx
lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536

The first four lines specify that the container should use the network bridge we created earlier.

Next, we define how the container’s UIDs and GIDs should be mapped to those on the host. Since our goal is maximum security, we’ll use unprivileged containers. To achieve this, we map the container’s IDs into a range of IDs that do not exist on the host. This ensures that even if a malicious process escapes the container, it will end up with no meaningful permissions on the host system.

Understanding idmap

Here’s a detailed explanation of how the idmap configuration works:

lxc.idmap = [type] [container_id] [host_id] [range]

  • [type] – Specifies which type of ID is being mapped. Options:

    • u for UID
    • g for GID

  • [container_id] – The first UID/GID inside the container to map. In our case it’s 0 (the container’s root).

  • [host_id] – The starting UID/GID on the host that container_id maps to. Here, 0 in the container maps to 100000 on the host. IDs increase incrementally:

    • container_id=1 → host_id=100001
    • container_id=1000 → host_id=101000

  • [range] – The size of the UID/GID block to map. We use 65536 to provide a full standard Linux ID range.

Example mapping table:

    | container_id       | host_id     |
    | ------------------ | ----------- |
    | 0                  | 100000      |
    | 1                  | 100001      |
    | 1000               | 101000      |
    | 65536              | 165536      |

Next, we need to inform LXC about the UID/GID mappings to use in our new container. We do this by adding the following line to both /etc/subuid and /etc/subgid:

root:100000:65536

This line means that the host user root can create UID mappings in the range 100000–165535 for LXC containers. It corresponds directly to the unprivileged container configuration we created earlier.

If you want to create another container with different mappings, for example mapping container_id=0 to host_id=200000, simply add another line to the subuid/subgid files:

root:100000:65536
root:200000:65536

Now we are finally ready to create our container using the configuration file we prepared. For this example, I’ll use the debian:trixie image as a base:

# lxc-create --config /etc/lxc/www.conf --name www -t download --- \
    -d debian -r trixie -a amd64

Verify the container is running:

# lxc-ls -f

Once the setup is complete, log into the container:

# lxc-attach www /bin/bash

Inside the container, you can install the software you need just like on a regular Linux system. For example, to run Firefox:

# apt-update
# apt-get -y install firefox-esr

Many X11 applications do not run well as root, so it’s best to create a dedicated user for running the application inside the container:

# /sbin/useradd -m -s /bin/bash www

To be continued...