mjhjmtu

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?