Enhancing x11 Application Security with LXC · dobrowolski.dev
2025-12-05
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?<br>After all, if a browser is compromised, the user’s entire home directory may be at risk.
Let’s mitigate this by using LXC to 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.
Networking Capabilities
First, we need to install and preconfigure LXC. Install the following packages:
# pacman -S lxc lxcfs
Next, we need to give our LXC containers networking capabilities.<br>To do that, edit the /etc/default/lxc file and append the following line to 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.<br>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<br>lxc.net.0.link = lxcbr0<br>lxc.net.0.flags = up<br>lxc.net.0.hwaddr = 10:66:6a:xx:xx:xx<br>lxc.idmap = u 0 100000 65536<br>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.<br>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.<br>In our case it’s 0 (the container’s root).
[host_id] – The starting UID/GID on the host that container_id maps to.<br>Here, 0 in the container maps to 100000 on the host.<br>IDs increase sequentially:
container_id=1 → host_id=100001
container_id=1000 → host_id=101000
[range] – The size of the UID/GID block to map.<br>We use 65536 to provide a full standard Linux ID range.
Example mapping table:
| container_id | host_id |<br>| ------------------ | ----------- |<br>| 0 | 100000 |<br>| 1 | 100001 |<br>| 1000 | 101000 |<br>| 65535 | 165535 |
Next, we need to tell LXC which UID/GID mappings to use in our new container.<br>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.<br>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<br>root:200000:65536
Spinning up the container
Now we are finally ready to create our container using the configuration file we prepared.<br>For this example, I’ll use the debian:trixie image as a base:
# lxc-create --config /etc/lxc/www.conf --name www -t download --- \<br>-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.<br>For example, to run Firefox:
# apt update<br># apt-get -y install firefox-esr
Many x11 applications do not run well as root, so it’s best to create a dedicated user to run the application inside the container:
# /sbin/useradd -m -s /bin/bash www
Setting up x11
Basic container configuration is complete, so let's jump right into configuring it to host x11 apps. First, we have to map the x11 socket. If you're currently running an X server, you'll find it under /tmp/.X11-unix.
We also need to give the container an .Xauthority so it can authorize against the X server. Simply mounting the host's file won't work: each cookie entry is keyed by hostname, and the client only uses the entry whose hostname matches the machine it runs on — which, inside the container, it won't. The fix is to replace the entry's family field with the FamilyWild wildcard (ffff) so it matches any host, then merge it into a fresh .Xauthority for the container:
: > /tmp/lxc.Xauthority && xauth nlist :0 | \<br>sed 's/^..../ffff/' | xauth -f...