Improve X11 security

[eriad25]

This is feature request. After first release of xlibre comes out i implore you to unless you already did to finaly start working on security for xlibre before you add any new feature.

[kingdomkind]

Please see xnamespace

X11Libre/xserver@269012b

https://github.com/X11Libre/xserver/blob/master/Xext%2Fnamespace%2Fns.conf.example

To my knowledge, it is currently WIP

[reaperx7]

Securing X11 isn't going to be easy without breaking a lot of applications without suitable workarounds in place while applications migrate in the fixes.

The was attempted 20 years ago by Sun Microsystems but failed to be accepted into the main tree because it broke too much, and nobody wanted to inform every project across the internet that used X11, "the new code will break your apps, please update your code".

The new way it could be done is by using exemptions for unsecured apps to use the legacy methods of unsecured execution while allowing newer apps and projects time to update to the new security protocols, but setting a time frame for the legacy unsecured execution to be phased out.

[ian-maurmann]

@reaperx7 Maybe there could be a way to put the user in control? To let them "allow" the apps that they've trusted for years, but it could also be a long-term solution to other stuff like screen-recording programs maybe.

(Not sure how easy / hard that would be to implement though, Just the idea that popped into my head.)

[eriad25]

Anyway i didn't suggest how to do just to finaly put some effort into security which was neglected for years. If something is happening regarding security that's start.

[kingdomkind]

Xnamespace will largely fix these issues, and also be optional to my understanding for those who don't wish to adopt it

[dec05eba]

Securing X11 isn't going to be easy without breaking a lot of applications without suitable workarounds in place while applications migrate in the fixes.

The was attempted 20 years ago by Sun Microsystems but failed to be accepted into the main tree because it broke too much, and nobody wanted to inform every project across the internet that used X11, "the new code will break your apps, please update your code".

XACE was added ~25 years ago by NSA and it does this, but yes it "breaks" applications because it returns errors by default when attempting to access root resources and the default behavior in libx11 is to crash the application if there is an error (it technically doesn't have to return an error, but that's what it does right now in the xorg server code when used with selinux). Xnamespace doesn't return an error, it instead isolated applications by namespace and as such shouldn't break most applications (except those that require root namespace access, such as screen recorders or window managers. These have to be added to the root namespace). Xnamespace uses the same xace hooks iirc.

[Slatepaws]

Maybe have a xnest instance that runs an older xserver to allow people to run programs that don't run under a newer xserver?

[ToneyFoxxy]

I sure hope X11 gets a security upgrade, there are a couple issues that are pretty terrible

[reaperx7]

I sure hope X11 gets a security upgrade, there are a couple issues that are pretty terrible

Most of the security issues luckily are client side only. I think there's only a few server-side issues which involve a vnc client level access only if memory serves. XACE addressed some of these for selinux from the NSA and SunOS. I think xenocara addressed things differently but with the same aspects in mind for OpenBSD (hence why getting them onboard here would be ideal).

[ghost]

OpenBSD has a different concept of the correct way to do security/application isolation than most other projects. Most people have resorted to shoving things into containers. Which is a lazy way that allows developers of applications to side step the problem. In OpenBSD they have pledge and unveil. Which restricts system calls and access to the file system. But these must be manually defined by the developer/package maintainer. Once privileges are defined and set in stone they are not allowed to change again for the life time of the application. If an application attempts to violate those rules it crashes. For example, something like Firefox is only given access to ~/Downloads/ by default and if it attempts to access any other part of the file system it's killed. If a user needs it to access other locations in the file system they can modify the rule set through config files.

See: https://man.openbsd.org/unveil.2 and https://man.openbsd.org/pledge.2

As far as I know no other BSD or Linux has a similar concept as the above.

A lot of the security issues with X are overblown for the average user anyway. Considering most are not running it in environments where multiple users are using the same system at the same time. The main issue is the web browser which is a can of worms all its own but can be easily isolated from the rest of the system by running it in a chroot/jail/container with its own instance of xserver. Or with the OpenBSD method of fine grained control to resources. Most other applications don't suffer from the issue web browsers have since they aren't running random untrusted code all of the time. They are also smaller, easier to audit and if they were malicious a secured X wouldn't gain you much in the way of security in the first place.

The main issue is how most Linux distros package applications and how they expect upstream to handle these types of bugs/exploits. If most OSs packaged software like OpenBSD did and the maintainers of those ports/packages took the time to add support for stuff like pledge/unveil and/or shipped things contained by default this wouldn't a problem. But they don't. I don't know of any distro that packages Firefox/Chrome forks in a container by default for example. The user is expected to set it up manually and most will not. Things like Flatpak aren't a solution to this problem either since their primary goal isn't security it's ease of running the application on a variety of different (but similar) systems.

There is nothing stopping anyone from packaging Xorg as it exists right now similar to how it's done in OpenBSD. Where it runs under its own user and privileges are defined and tightly controlled to ensure it doesn't have access to everything at all times. But even running as setuid as was the "secure" method in the past wasn't as large of an exploit as people like to pretend. Also bringing in massive chunks of code like logind is not really any more secure either. You've just moved the problem from one place to another.

There is room for improvement but you have to keep in mind that the only way to truly secure a system is to restrict the user's ability to access and modify it to the point where they aren't really allowed to do anything but run a per-determined set of applications which themselves are restricted. Then you must consider the fact that most systems have tons of code we can't read running on them all of the time as well. Firmware, binary blob graphic drivers, UEFI, CPU microcode etc. You can have the most secure kernel and userland in the world but none of it matters if there is something between you and the hardware that is riddled with bugs and beyond your control.

[darkhog]

Any security issues in X are theoretical at best, since to actually exploit it you first need to... be able to execute code at the target machine, at which point you can bypass GUI (any GUI, be it X11, Wailord, or even the raw framebuffer) entirely to exfiltrate (or put in) any data you want. There's no malware exploiting X in the wild, because there's simply no need to exploit X to make successful malware.

[Slatepaws]

Any security issues in X are theoretical at best, since to actually exploit it you first need to... be able to execute code at the target machine, at which point you can bypass GUI (any GUI, be it X11, Wailord, or even the raw framebuffer) entirely to exfiltrate (or put in) any data you want. There's no malware exploiting X in the wild, because there's simply no need to exploit X to make successful malware.

Same could be said of most of the cpu vulnerabilities. Still it only takes another exploit in something else to allow local usage of code.
That being said. Yes most of the stuff is still hypothesized to exist, no proof as of yet such things do in the code base.

[eriad25]

Security for beginning doesn't have to be anything crazy, but something basic that helps as starting point. If you want good security for x11 perhaps much easier way to implement it would be via compositor, x11 is set of protocols and alone it doesn't work, but if you let compositor to provide some form of security as support to x11 you're good to go. Xnamespace is good start but it is easier to implement that through compositor instead of x11 directly. Of all x11 compositors i know of picom is the best and most advanced. If it doesn't have already picom devs could provide security for x session through it. If you want x11 to improve, do not follow monolithic design principle. If you want x11 to get better and less buggy modularity is a must. X11 is set of protocols and nothing more. Protocols are good the way they are but how they're implemented that's something else and that also goes for security.

[eylles]

there are many ways to do security but i want to propose an idea, now this idea is not perfect nor the be all end all panacea to make x11 security a reality so i do not expect it to be implemented but just from it out here, but rather to contribute to the conversation and have the proposed ideas for consideration.

Mandatory Access Control of x11 application properties and keystrokes through a virtual filesystem

this proposal is intended to follow unix philosophy to some extent.

refference of terms that will be used during the proposal

• DAC: directionary access control, the classic unix access control paradigm built around file access permissions
• MAC: mandatory access control, a superset of DAC managed by frameworks that interact with the kernel, implemented on multiple unix and unix like operating systems and limit what files can be read and written by which programs, on linux the most popular MAC implementations are SELinux, AppArmor, SMACK.
• VFS: Virtual File System, an interface that provides access to data structures, parameters, variables and other information in the paradigm of a directory where every piece of data is mapped to a file, for example the linux sysfs and procfs which respectively expose parameters, information and tunables of the linux kernel, and the system's process table along the specific information of every process.
• x11 window primitives: through this proposal i will use the term x11 window primitives to refer to the collection of functions used to: get properties of windows, set properties of windows, send key events/syms to windows, listen (snoop) keystrokes, key events, key syms, mouse events, mouse keys from other windows, every other function that would allow to get information from a different window than those that belong to the program.

changes to implement for the proposal

• enforce use of the _NET_WM_PID atom by modifiying the x11 functions resposible of window creation and reparenting, this will guarantee strong programatical correlation between the windows and the process that owns them as the windows will always have the PID of their process amont their props; implementing this is more than trivial as the work has already been done in this repo it just requires upstreaming into x11libre.
• implement a vfs interface to the table of windows in the current x11 server, this would be rather similar to the x11fs project but would have to differ in order to have the names and PIDs of the processes that own each window be more significative.
• modify the x11 window primitives so that they have to go through the vfs interface.

those are all the changes reduced in bullet points, in spite of the seemingly "trivial" nature of the 3 stages that does NOT reflect the actual challenge of implementing the changes.

security paradigm

the security paradigm possible by this changes does lean way more to the x11 paradigm of "everything is open" than to the wayland one of "trust no one, nothing is open, no one can know anything", however would allow for effectively locking down untrusted and less trusted applications from being able to interact with other windows to snoop input or even send malicious input by leveraging a MAC framework.

by re-routing all the primitives throught the proposed x11vfs interface it would be "easy" to simply leverage one of the many MAC frameworks and add rules to prevent programs from having read/write access to parts of or even the whole x11vfs and thus isolating them from interacting with programs in the xserver.

as the advantages this means that none of the x11libre maintainers have to come up nor maintain a security framework specific for x11libre, on top of reducing maintainer load this means there's no need to reinvent the wheel and that existing frameworks can be used simply extending the per application rules.

on the disadvantages, 2 arise immediately:

potential performance reduction: as instead of receiving the information directly from the xserver getting the properties of an x11 window would inquire the performance overhead of every file read operation, for setting properties it will hit file write overhead, no idea how much the performance loss from this could be, it can range from meaningless to very noticeable.

statically compiled programs not working as intended: any program that is statically compiled against a set of x11 libs that do not use the x11vfs interface will not work as intended or outright crash.

these 2 considerations may be reason enough to provide 2 versions of the x11 window primitives, the traditional version for compatibility and performance (if needed) and the secure version that makes use of the x11vfs that can be ruled by a MAC framework.

[reaperx7]

Many applications don't build for or try to use static libs much any more, which is luckily alleviating one problem. Even then, most stuff can be easily rebuilt against newer libraries.

In fact many distributions and projects recommend stripping static libs to not only save space, but to ensure dependencies don't break when newer versions arrive.

[eylles]

Well it is an idea.

[callmetango]

Thank you for your contribution! We currently restructured the "Ideas" discussions and accordingly this discussion will be moved to the X11Libre 4 Good Ideas For Later category.