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

61–70 of 78 posts

Re: Enhancing x11 Application Security with LXC (2025)

#61

Post by orangeboats »

Asooka wrote: post #48
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).

Wayland was started 18 years ago. When it was conceived, X11 was 20 years old. In 2 years, we should probably start talking about replacing Wayland with a modern display server... 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 tw…

>Wayland was started 18 years ago.

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.

Re: Enhancing x11 Application Security with LXC (2025)

#62

Post by uecker »

orangeboats wrote: post #59
uecker wrote: post #45

Earlier quoted context omitted.

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

No, there is already a secure mode which in the past worked fine but was bit too restrictive for modern clients, and there already exist hooks for fine grained access control.

Re: Enhancing x11 Application Security with LXC (2025)

#63

Post by uecker »

ChocolateGod wrote: post #53
uecker wrote: post #44

Earlier quoted context omitted.

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.

Of course they can! How do you think a debugger works?

Re: Enhancing x11 Application Security with LXC (2025)

#64

Post by throw_await »

mike_hock wrote: post #37
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.

> until one considers the practical implications 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.

Every program can listen to keypresses via /dev/input

Re: Enhancing x11 Application Security with LXC (2025)

#65

Post by [deleted] »

throw_await wrote: post #64
mike_hock wrote: post #37

Earlier quoted context omitted.

> until one considers the practical implications 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.

Every program can listen to keypresses via /dev/input

[deleted]

Re: Enhancing x11 Application Security with LXC (2025)

#66

Post by nsingh2 »

throw_await wrote: post #64
mike_hock wrote: post #37

Earlier quoted context omitted.

> until one considers the practical implications 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.

Every program can listen to keypresses via /dev/input

This is false. A process needs read permission on the relevant `/dev/input/` device, typically by running as root or as a user in a group like `input`. Normal desktop users generally should not be in the input group. Regular applications receive keyboard input through the compositor/windowing system.

Re: Enhancing x11 Application Security with LXC (2025)

#67

Post by hulitu »

toenail wrote: post #24
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).

Is wayland going to be aroud in another 10 years, or it it the new pulseaudio?

No, but Waywire will.

Re: Enhancing x11 Application Security with LXC (2025)

#68

Post by loeg »

lotharcable wrote: post #14
calvinmorrison wrote: post #3

Xlibre (the only current actively developed implementation of a X11 server) has a new extension - XNamespace to address some challenges as well. https://github.com/X11Libre/xserver/blob/master/doc/Xnamespa...

XWayland is actively developed. XFree86, which is the "standalone DDX" you see on X11 desktops, is being actively maintained.

XFree86 hasn't been relevant for over 20 years, when Xorg forked in 2004.

Re: Enhancing x11 Application Security with LXC (2025)

#69

Post by ChocolateGod »

uecker wrote: post #63
ChocolateGod wrote: post #53

Earlier quoted context omitted.

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

Of course they can! How do you think a debugger works?

Because a debugger launches the target process as a child process and thus has access to its memory?

/proc/sys/kernel/yama/ptrace_scope is usually set to 1 on non-Selinux distros.

Re: Enhancing x11 Application Security with LXC (2025)

#70

Post by uecker »

ChocolateGod wrote: post #69
uecker wrote: post #63

Earlier quoted context omitted.

Of course they can! How do you think a debugger works?

Because a debugger launches the target process as a child process and thus has access to its memory? /proc/sys/kernel/yama/ptrace_scope is usually set to 1 on non-Selinux distros.

Without this flag it can also attach to existing processes and on my Debian this is set to zero.
Post reply on HN