I have little experience with lxc but I guess waypipe could be an option too.
https://github.com/X11Libre/xserver/blob/master/doc/Xnamespa...
X itself always bothers me. Xeyes is cute until one considers the practical implications…
while being one of the few apps that executes Remote Code really well.
The author of the phoenix x server has blogged about it, iirc.
https://docs.redhat.com/en/documentation/red_hat_enterprise_...
In all seriousness, it is another stark reminder why you never rewrite from the ground up. Especially when you're replacing a foundational technology like the display server. In the same time Microsoft reworked their display driver model twice without requiring a single change from application developers. The Linux world doesn't have that many application developers, we should not be asking them to continually chase newer and newer APIs. A rolling stone gathers no moss.
edit: phoenix was the name: https://github.com/external-mirrors/phoenix#phoenix
https://github.com/X11Libre/xserver
In the end Red Hat failed to kill off X11. Let's see what happens next. The GTK devs already rejected patches for maintaining the toolkit further for the xorg platform, following their "GTK5 will no longer support x11" agenda. Would be kind of great to have a universal GUI toolkit that would work rather than have toolkits controlled de-facto by private companies who just willy-nilly throw out support for this or that platform at their own selfish discretion. Though, someone else now helps maintain gtk2, though most of the patches are in regards to fixing bugs, ensuring that it can be compiled and so forth. https://git.devuan.org/Daemonratte/gtk2-ng
XFree86, which is the "standalone DDX" you see on X11 desktops, is being actively maintained.
what's the problem with xeyes? it reads data on your computer and displays it. Just like vim or cat.
If, for some reason, you want to run a program that you don't trust, you should sandbox it from the outside. But granting full rights to distro-provided programs like vim or xeyes is perfectly sane. Just like you trust your kernel.
However I use XFCE, where you can set directly the DPI values of the monitors, so that everything will work fine. I have heard Gnome users complaining about problems with HiDPI, but those are not caused by X11, but by a bad Gnome UI for desktop settings.
So HiDPI is not something at which Wayland is better than X11 and there is no reason to avoid HiDPI. At a higher DPI, OTF/TTF typefaces are rendered much more beautifully and reading becomes more comfortable.
I do not know if Wayland has any advantage at mixed DPI, because I have rarely used such configurations.
Oh no, not this again. The design of Wayland started 18 years ago, but the stabilization happened 14 years ago, and the _convincing_ across the ecosystem obviously happened way later than that.
I would put the year closer to 2016, when distros started to consider Wayland as an option.
You mean run everything distro-provided as root?
There are reasons systems don't do that any more. Even distro-provided services are often setup in a way to no run with full rights. Can you imaging reasons why this is done?
What was neglected is doing the same on user level, which should be done for pretty much the same reasons.
Plasma itself is an example of bad UI redesign (but a far cry from Gnome).
Saying this after the whole XZ utils ordeal has happened is quite interesting.
Can you really guarantee that your distro is not compromised? And if it is compromised, how can you easily _discover_ that a program is doing something strange?
X11 (the one that most people are familiar with, not the locked down one with X security -- because the latter introduces compatibility issues) does not have an access control model where programs can request for specific permissions.
In other words, xeyes would just work(TM) without the user granting it permission to read global mouse pointer position. And simultaneously, the same is true for $compromised_distro_provided_program.
You failed at that step.
The practical implication is that every other X11 app can also read your input even when it's not in the foreground.
Sure, major version revisions that break the previous API exist. But in my experience there's a new one every couple of years, like branches on a tree, the main trunk will never change.
You do realize that XZ was on github. (Microsoft, PRISM etc.)
1 malicious package almost got distributed in 20 years of debian history?
>granting full rights to vim or xeyes
I'm not sure I get what's being discussed here. Standard Xorg runs without root already. And Xeyes definitely 100% run without root, I get why you would you run vim on root, to edit root files, but also don't? Especially if you have plugins, run simple programs like echo>> , ed, grep or nano.
Basic X client isolation (not using XACE just Xsecurity) would have worked for sandboxed applications with some minor changes (allowing access to some basic modern extensions, I had a local patch for this once). There is really not fundamental issue in X that could now allow isolation of clients.
It is my understanding that XACE doesn't actually provide any security features itself. It just provides the "hooks" to implement security extensions. Like LSM feature in Linux kernel. You have to install a additional X11 extension to do something useful with it.
So the most common X11 security extension is going to be xcsecurity which enables the SECURITY extension. It allows a course permission model were applications can be designated as "Trusted" or "Untrusted". That is going to show up in many Linux distributions.
However all applications default to "trusted" because if they are untrusted they tend to cause lots of other annoying problems and crashes a lot of apps, apparently.
In practice the only place it shows up is if you are using "ssh -X". That uses the security extension by default. Which is why there is also a "ssh -Y" that disables it for applications that it breaks.
This sort of thing is why to fix X11 security you have to give up backwards compatibility and create a new X version.
Oh, wait, that is what the X developers did with Wayland.
This is a problem in many projects now. xserver and mruby for instance also succumbed to claude. It seems claude is the ultimate virus. It leaks into almost every project now. So I am not sure it can be used as differentiating criterium here merely for being claude AI slop. I've noticed a lot of documentation is now totally useless though; claude slop is just unreadable to me. It's like a person who is not able to think, wrote the documentation. I did not have this issue back when real humans wrote documentation, even though high quality documentation was always rare anyway. But, for instance, Jeremy Evans in his projects tends to write high-quality documentation in general, and I can understand it fine, whereas if you look at matz spinel, I have no idea what the AI slop in the README is really trying to convey. Or on ffmpeg, a german dev used AI slop to try to create some proposal, and someone else pointed out that this is pointless and impossible to read and understand, yet the original guy did not understand why real people don't want to be AI slop spammed. It's very strange.
Unless your distro changes the default to make "ssh -X" and "ssh -Y" behave the same which popular distributions do.
Then you would have to cut everything provided by the X protocol into many, smaller, controllable pieces. Because if the permission control is just a switch that says "ability to communicate with the X server", then the whole exercise is rather moot, isn't it.
And when you cut the protocol into smaller pieces...
Also, are we still assuming that we would still get only one attack over 20 years, instead of the frequency increasing to, say, one attack per year?
---
But those are not my original point, XZ utils was just an example.
My original point is that: why should we not practice defense-in-depth, where we make sure malwares have to jump through multiple hoops (and hope that they trip on one of them!) in order to launch an attack?
>I'm not sure I get what's being discussed here
I think it's the implication that any GUI program running under X can see any other GUI program and watch the user's interaction with the other programs. Vim is a CLI program though though...
Unless you're running everything as root, applications can not read eachothers memory.
This is rather incomplete. For instance, gtk devs already threw out tons of old code in GTK4. Wayland also has fewer features than xorg; and there are also fewer choices available. I noticed this with regards to WMs/DEs. I am not even going to issues wayland has with regards to certain video graphics - that's another not mentioned issue here.
You are trying to pick individual cherries.
> This sort of thing is why to fix X11 security you have to give up backwards compatibility and create a new X version.
I don't think so: https://github.com/X11Libre/xserver
Let's have a look in a little while. I myself hope for better and more transparent information at all times. Probably others want better security overall. Would it not be somewhat interesting if wayland were to be abandoned eventually due to having too few useful features compared to xserver?
for example standardized window management, left as an exercise to the GUI lib and the compositor? and woop woop X11 GUI apps need to be rewritten to support window management on WSL (Wayland based) and the network reconnect on hybernate also broke.
But at least Games are faster, aren't they...
? Debian has a track record and a reputation. And Arch Linux has another, much worse, track record and reputation. You argue that it can happen to any distribution, yet it happens to one and not the other on a continuous basis, maybe it's not luck and maybe it has something to do with design and quality, quite possibly with the fact that packages are vetted and tested thoroughly before releases instead of being pushed as soon as they are available without much review.
>Also, are we still assuming that we would still get only one attack over 20 years, instead of the frequency increasing to, say, one attack per year?
If you want to make a wild bet, go to the casino. The probabilities given the current data is that there's roughly 1 malicious package over 20 years (I'm rounding up and counting the almost as a vulnerability).
>My original point is that: why should we not practice defense-in-depth, where we make sure malwares have to jump through multiple hoops (and hope that they trip on one of them!) in order to launch an attack?
I'm not convinced this is true at all. First of all you can run X servers under different users and as such isolate applications per user. As mentioned by other users, Xephyr makes nesting possible so as to not depend on root.
Thirdly, to the extent that it is possible to introduce a vulnerability through manipulating an X window, it will be possible to do so via other means like filesystem manipulation. That is, it's a system design tradeoff that if you run a malicious process as a user, the rest of your processes are almost guaranteed to be vulnerable.
Fourthly. Virtualization isn't a magic invokation that provides security on demand. You need to learn how the stuff works. For example, in the clusterfuck of container configuration, there's an Xauthority being shared that essentially undoes the whole containerization.
Virtualization is like a 5 inch thick wall, which sounds alluring to people that don't know what's on the other side of the perimeter, but it turns out that in order to do something useful, you need doors, and a house with 5 inch thick walls and a door without a key, is just as unsafe as a house with regular brick walls and a door without a key.
Virtualization is an antipattern, a patch to be applied under considerable stress, a glass to be broken in case of emergency, a move you pull when an engineering has been fired long ago and you don't want to learn about their system, a move you pull if you are in a big org where the role of the one who writes code and the one who runs commands on a system are separated by 5 more layers of roles, a hat on a skyscraper where we want to add the final few meters with pyramidal engineering, hoping that nobody asks us to add another floor.
Don't virtualize if you can avoid it.
I don't want my display server/compositor to have a print server.
Because Wayland is a strictly a window management protocol focused on policy over mechanism.
> I am not even going to issues wayland has with regards to certain video graphics - that's another not mentioned issue here.
We also aren't going to mention issues Xorg or XLibre have with some graphics setups, because that's neither here nor there. This is a thread about security.
> I don't think so: <XLibre github repo link>
Didn't XLibre break some applications when launched?
> Would it not be somewhat interesting if wayland were to be abandoned eventually due to having too few useful features compared to xserver?
It would be interesting to see Wayland abandoned for a better protocol/set of protocols, xserver is neither a protocol nor really better.
Are you seriously suggesting that the number of people attacking computer systems across the world, is the same as 20 years ago?
Wow.
No wonder why the X11 vs. Wayland argument can last for so long on HN when it's mostly ended in other Linux communities (sporatic controversies aside).
---
Furthermore. Nowhere did I mention the word virtualize in my original comment, and I do not think my comment warrants the paragraphs upon paragraphs of virtualization-bashing.
/proc/sys/kernel/yama/ptrace_scope is usually set to 1 on non-Selinux distros.
It can't have broken as many things as Wayland
Am I? Are you suggesting that systems 20 years ago were as secure as modern systems?
If the PoW cybersecurity theory is correct, the difficulty of atacking and defending is constant over time.
Wayland is a new protocol, without an established implementation; X11 is an older protocol, while Xorg was an established implementation and XLibre is trying to modernize its codebase. Recall https://xkcd.com/1172/ .
I am not the one arguing to weaken cyberdefenses and most certainly I did not write multiple paragraphs to bash on security measures ;)
2025-12-05
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 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.
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. 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
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.
idmapHere’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:
[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 sequentially:
[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 |
| 65535 | 165535 |
Next, we need to tell LXC which 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 to run the application inside the container:
# /sbin/useradd -m -s /bin/bash www
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 | \
sed 's/^..../ffff/' | xauth -f /tmp/lxc.Xauthority nmerge -
# Replace :0 with your $DISPLAY value
Lastly, we have to make sure we've set the following environment variables:
DISPLAY - set this to the host's DISPLAY value
XAUTHORITY - set this to the path where the lxc.Xauthority file will be mounted inside the container
To implement these steps, let's edit the container's configuration file and add the following lines. Note that this is the per-container config that lxc-create generated under /var/lib/lxc/www/config, which is distinct from the /etc/lxc/www.conf template we passed at creation time:
lxc.environment = XAUTHORITY=/tmp/lxc.Xauthority
lxc.environment = DISPLAY=:0
lxc.mount.entry = /tmp/.X11-unix tmp/.X11-unix none bind,optional,create=dir,ro
lxc.mount.entry = /tmp/lxc.Xauthority tmp/lxc.Xauthority none bind,optional,create=file,ro
One last detail: since we built an unprivileged container, its IDs are shifted by our idmap (container UID 0 maps to host UID 100000). The .Xauthority file, however, was created by xauth with mode 0600 and is owned by your host user, whose UID falls outside that mapped range. Inside the container the file therefore shows up as owned by nobody, and our container user can't read it - so X would still reject the connection with Authorization required.
The simplest fix is to make the cookie file world-readable on the host:
chmod 644 /tmp/lxc.Xauthority
If you'd rather keep it at 0600, chown it to the mapped host UID of the container user instead (for the www user at container UID 1000, that's host UID 101000).
If everything went smoothly, you should now be able to run the browser we installed earlier and see its window on your host's desktop:
# lxc-start www
# lxc-attach www -- su www -c firefox
Optionally, if you want hardware-accelerated rendering and video decoding inside the container, you can pass through the GPU by mounting /dev/dri:
lxc.mount.entry = /dev/dri dev/dri none bind,optional,create=dir
Audio follows the same pattern as the display. PipeWire ships a PulseAudio-compatible server, so we can expose a PulseAudio socket on the host and bind-mount it into the container, just as we did with the x11 socket.
First, install the audio packages inside the container so the application can use the socket:
# apt-get -y install pulseaudio pipewire-pulse
Next, tell PipeWire to open a dedicated PulseAudio socket by adding it to server.address in ~/.config/pipewire/pipewire-pulse.conf:
pulse.properties = {
# ... keep the existing defaults ...
server.address = [
"unix:native"
"unix:/tmp/pulse-socket-0"
]
}
Reload the PulseAudio server so the socket appears:
systemctl --user restart pipewire-pulse
/tmp/pulse-socket-0 should now exist. Next, mount it into the container and point PULSE_SERVER at it. Add the following to the container config:
lxc.environment = PULSE_SERVER=unix:/tmp/pulse-socket-0
lxc.mount.entry = /tmp/pulse-socket-0 tmp/pulse-socket-0 none bind,optional,create=file,ro
Unlike the cookie file, the socket is world-accessible, so the unprivileged-container ownership issue from before doesn't apply here — there's nothing to chmod. Restart the container and it should have working audio.
We now have a GUI application running inside an unprivileged LXC container, with its display and sound forwarded from the host. If the browser is compromised, the blast radius is a container whose UIDs map to an unused range on the host — your home directory and the rest of the system stay out of reach.
The isolation isn't free, though, and it isn't absolute. Every channel we opened — the X socket, the PulseAudio socket, optionally the GPU — is a hole through the wall, and each one widens what a compromised process can touch. The audio socket, for instance, grants capture as well as playback. Forward what the application actually needs and leave the rest out; that trade-off is the whole exercise.
The same setup works for any untrusted GUI application, not just a browser. You can tighten it further with seccomp or AppArmor profiles, but even as it stands, a compromised app is now boxed in rather than sitting on top of your home directory.