Does firejail rely on the application crashing out and why can't we use named pipes to .Xauthority?

Question

The purpose of jailing an Xorg application is to prevent it from accessing @/tmp/X11/X0 and /tmp/X11/X0 and then re-using its MIT-MAGIC-COOKIE to steal from other apps that are connected to the X server.

The cookie is used to obtain a file-handle/socket abstraction to Xorg the first time the app connects. Were an evil hacker to segfault the app and start a shell, he won't have access to this file-handle/socket abstraction and therefore needs the original MIT-MAGIC-COOKIE from .Xauthority AND he needs access to the /tmp/X11/X0 file/abstract-socket TO CREATE a new Xorg CONTEXT.

The idea behind firejail and Linux namespaces is to hide these resources from him and prevent him from creating a fresh Xorg context.

To do this firejail relies on Linux Namespaces and moves the application into a new namespace where /tmp/* isn't present. It also gives the application a new bridge interface using --net= Therefore, the application cannot see a .Xauthority file AND it has no way of communicating with Xorg. Because the application is communicating over a bridge interface it can see the internet/assuming it's allowed but it's view will be limited by the firewall on br0 etc

The application itself USES its Xorg socket-pointer to talk to Xorg using shared memory and SO LONG as it retains this pointer it can do so indefinitely.

So firejail security relies on the application crashing out completely from memory and LOSING it's Xorg CONTEXT/pointers? But the hacker can segfault into the application and rewrite it's code and still retain the Xorg context? But this is a risk we have to take - maybe prevented by Apparmor/SELinux and monitoring systemcalls?

However why don't we use named-pipes instead? Create a named-pipe/.Xauthority and export XAUTHORITY and start the app - it'll block, so on the Server end, run something that writes the current cookie and changes it once the app has started. Therefore if the app segfaults out, the hacker is just a normal user or restricted with no cookie: there's no hope in heck of the hacker ever stealing the new cookie, especially if you clean out/nuke the user/remove all his files and start afresh every app-run.

What's firejail doing that's different from this? If he needs the app to start he has to provide the .Xauthority and socket file.. then what - does he move the app into a new NS - how does he know when to? Many apps poll the .Xauthority multiple times so how does firejail know when to hide these resources and how exactly does it hide these resources?

Answer 1

The purpose of jailing an Xorg application is to prevent it from accessing @/tmp/X11/X0 and /tmp/X11/X0 and then re-using its MIT-MAGIC-COOKIE to steal from other apps that are connected to the X server

Um ... no? If you read e.g. this guide,

The sandbox replaces the regular X11 server with Xpra or Xephyr server. This prevents X11 keyboard loggers and screenshot utilities from accessing the main X11 server.

So the purpose if jailing an X application is to completely prevent it from accessing the main server, and instead letting it access a proxy server. Even if the application tries tricks with the proxy server, that won't affect the main server.

I am not sure what scenario exactly you describe, but any X application that has access to the main server somehow, even if initial authorization with MIT cookies was not done by the application itself, can then do tricks on this server, like key logging or accessing other windows. It doesn't have to crash to do that. So doing the initial authorization for the application and then preventing it from re-authorization doesn't help in any way.

Have you possibly missed that the main point of starting the jailed application in a particular way is to make it access a proxy X server?

Edit

I'm just trying to understand what EXACTLY firejail's doing different from traditional xauth/.Xauthority to make the jailed app secure.

Firejail is showing the app an X server proxy, and is preventing the app from accessing the main X server. That's all. The traditional xauth mechanism is exactly the same, both between the app and the X proxy, and between the X proxy and the main X server. (And yes, of course the X proxy needs to access the main server, or, there needs to be a program that can access both the main X server and the X proxy. But these programs are trusted, unlike the app).

and is then relying on Namespaces and to prevent that cookie from being compromised.. and as an added measure hiding the Xorg socket.

No. The point of namespaces is to make the main X server communication endpoints inaccessible. As in "they don't exist". It's not really "hiding" anything ("it's there but you can't see it"). It's no longer there, as far as the jailed application is concerned. In the same way a Docker container uses namespaces to pretend to the applications in the container that they are running in a completely different environment.

Not having the jailed app see the main X server communication endpoints would already be sufficient, but of course there's no reason why the jailed app should see valid MIT cookies for the main X server.

Named pipes really have nothing to do with it. Nor have crashes. Nor has the way the X authentication mechanism works.

Answer 2

So i emailed the Xorg mailing list and they were quite helpful, so this is how it all works.

Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local :0 -seat seat0 vt7 -novtswitch is the command you use to turn off listening except on UNIX Domain sockets (ripped from debian).

This will result in /tmp/X11/X0 and @/tmp/X11/X0 abstract sockets being created.

Xorg receives a cookie over this pipe/socket (written by the program using Gtk/Qt-->Xlib[.Xauthority]) and compares it, with its internal cookie, given to it by XDM. If they match Xorg will create its internal context and associate this context with the IP:Port [for tcp/ip connections] or app FD [for sockets][Named Pipes Socket/FD creation]1.

Basically each app writing to /tmp/X11/X0 results in Xorg creating a unique FD at its end. If the app dies and exits then this FD is closed by Xorg but if the app is injected into, then this Xorg FD/context IS NOT destroyed and the virus/evil-app can spoof the app and continue talking to Xorg. If the app is using a network/tcp then this is even easier since Xorg just uses IP:Port to authenticate after XOpenDisplay/MIT-COOKIE [cookie is only used for one API call to Xorg].

The app could, if it wanted to, retain the COOKIE in its memory thus allowing the hacker to steal the COOKIE but this auth bit is Xlib's job. Firejail doesn't really guard against cookie theft. What it does is use Xvfb to render the application GUI and then send the pixmap to the Xorg server by using Xpra-which is divided into two parts - a client Xpra and a server Xpra (The Xpra docs/readme explains that bit). Because the server only sees pixmap and no API calls from the trusted-proxy/Xpra-server/client/whatever it's protected by its Burqa and therefore safe. However the rapists are still running around because Xorg's weak and pathetic with no security whatsoever :p

It's a lot of duct-tape holding it all together and its not very neat and efficient - though I guess very debatable. Xorg has 0 security besides that onetime cookie verification - it was designed for a different era so.. I haven't got anything to work so far. I suspect it'll be easier to write a bash script to do the cgroup/resource-limit and namespace rather than use firejail which uses all sorts of shady hacks and is in C for whatever reason. As for Xorg.. I need to readup on Xvfb and try to extract/send the data to Xorg via the jail.