Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enhancing x11 Application Security with LXC (2025)

dobrowolski.dev

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Enhancing x11 Application Security with LXC (2025)

#51

Post by yjftsjthsd-h »

fluffybucktsnek wrote: post #26
shevy-java wrote: post #21

Earlier quoted context omitted.

> that is what the X developers did with Wayland 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 ind…

> Wayland also has fewer features than xorg; and there are also fewer choices available 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…

> Didn't XLibre break some applications when launched?

It can't have broken as many things as Wayland

Re: Enhancing x11 Application Security with LXC (2025)

#52

Post by adrian_b »

_jackdk_ wrote: post #30
ElijahLynn wrote: post #18

Is X11 going to be like IE6. Still around in another 10 years after it was intended to be deprecated across all major distros (2025/2026).

The problem is that Wayland just isn't a compelling alternative for many people, so they don't move. For me, I see no benefit because I got used to avoiding HiDPI and don't have a mixed-DPI workspace. For some bizarre reason they made each compositor implement input-handling separately, so for example artists might have to switch compositor just to use their tablet of choice. And worse yet, some people with input acc…

I have used only HiDPI monitors with X11 on Linux for about a dozen years and it has always worked perfectly.

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.

Re: Enhancing x11 Application Security with LXC (2025)

#53

Post by ChocolateGod »

uecker wrote: post #44
ChocolateGod wrote: post #12

Earlier quoted context omitted.

> XACE Which is configured by default on what distros?

Most of the time applications can read each other's memory, so protecting the display does not make much sense. 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.

> Most of the time applications can read each other's memory, so protecting the display does not make much sense.

Unless you're running everything as root, applications can not read eachothers memory.

Re: Enhancing x11 Application Security with LXC (2025)

#54

Post by ChocolateGod »

shevy-java wrote: post #21
lotharcable wrote: post #13

Earlier quoted context omitted.

Nowhere (and everywhere). 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 permi…

> that is what the X developers did with Wayland 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 ind…

> Wayland also has fewer features than xorg

I don't want my display server/compositor to have a print server.

Re: Enhancing x11 Application Security with LXC (2025)

#55

Post by yjftsjthsd-h »

ChocolateGod wrote: post #54
shevy-java wrote: post #21

Earlier quoted context omitted.

> that is what the X developers did with Wayland 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 ind…

> Wayland also has fewer features than xorg I don't want my display server/compositor to have a print server.

And I do want mine to tell a11y programs what windows exist.

Re: Enhancing x11 Application Security with LXC (2025)

#56

Post by yjftsjthsd-h »

TZubiri wrote: post #35
ElijahLynn wrote: post #18

Is X11 going to be like IE6. Still around in another 10 years after it was intended to be deprecated across all major distros (2025/2026).

X11 fine Youngins just don't wanna learn it

Well, that's a bit far. X11 sucks, even if its would-be successor sucks in other ways.

Re: Enhancing x11 Application Security with LXC (2025)

#57

Post by hulitu »

mid-kid wrote: post #6

For an article written late last year I hoped for a little more awareness of how massive a security hole granting full, unfiltered access to the X11 server is. Granted, any sandboxing is better than none, but firefox is one of the few apps that already sandboxes itself really well, and with a blog title like that it might be good to touch upon things like nested X servers such as Xephyr.

> firefox is one of the few apps that already sandboxes itself really well,

while being one of the few apps that executes Remote Code really well.

Re: Enhancing x11 Application Security with LXC (2025)

#58

Post by hulitu »

orangeboats wrote: post #33
enriquto wrote: post #29

Earlier quoted context omitted.

> Xeyes is cute until one considers the practical implications… 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.

> But granting full rights to distro-provided programs like vim or xeyes is perfectly sane 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…

> Saying this after the whole XZ utils ordeal has happened is quite interesting.

You do realize that XZ was on github. (Microsoft, PRISM etc.)

Re: Enhancing x11 Application Security with LXC (2025)

#59

Post by orangeboats »

uecker wrote: post #45
orangeboats wrote: post #33

Earlier quoted context omitted.

> But granting full rights to distro-provided programs like vim or xeyes is perfectly sane 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…

It is the same issue with all sandboxing solutions. If your program does not work without giving it excessive permissions, it does not work. If we want to move to a version with minimal privileges, X would still seem like a good platform to work on this. But one would have to work on it, not decide that everything needs to be rewritten all the time.

> If we want to move to a version with minimal privileges

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...

Re: Enhancing x11 Application Security with LXC (2025)

#60

Post by orangeboats »

TZubiri wrote: post #34
orangeboats wrote: post #33

Earlier quoted context omitted.

> But granting full rights to distro-provided programs like vim or xeyes is perfectly sane 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…

> the whole XZ ordeal 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 o…

Obviously, XZ happened on Debian. But $malware can occur on any Linux distribution at any time. For a recent example just look at Arch Linux.

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...

Post reply on HN