Xpra Isolation of Containerized X11 Applications

[BawdyAnarchist]

Hi there. Was hoping to get feedback on a simple xpra setup.

BACKGROUND: I'm building a containerization schema with FreeBSD Jails, to emulate Qubes (Jails are kernel-level virtualization). X11 jails access the host display with a nullfs_mount (called bind mount in Linux) to the host's .X11-unix socket. Meaning that all X11 jails share that socket, and can see each others keystrokes and windows. Not good.

XPRA SETUP: Quite simply I maintain the above setup, but run a startup script inside each jail: xpra start :100 ; xpra attach :100 ; setenv DISPLAY :100. (Other jails get incremented DISPLAY numbers). Testing this appears to have successfully severed visibility of screens and keystrokes between jails. xinput test <kbd_dev> and launching a screenshot tool both show nothing when the focus moves to a window belonging to another jail.

While on the surface this seems to work and it's definitely an improvement over the current situation, I'm still somewhat concerned about jails sharing the same unix socket with the host. But perhaps the nature of how that socket functions in combination with the jailed xpra server/client, makes it a low attack surface vector?

Thanks for taking the time to read this. Looking forward to any feedback people might have.

[totaam]

xpra start :100 ; xpra attach :100 ; setenv DISPLAY :100

Not a good start..
Use xpra start :100 --attach=yes
Don't use setenv DISPLAY :100 to start applications as the environment will be incomplete, use xpra start --start=app or xpra control :100 start app.

Meaning that all X11 jails share that socket
(..)
I'm still somewhat concerned about jails sharing the same unix socket with the host

I think a better approach would be to only expose the xpra socket, potentially using a different bind mount for each one.
Then run the xpra client(s) outside the jail.
That's how isolation is usually done.
I don't really see the benefit of running the xpra client from within the jail, and as you found out this requires exposing the X11 server socket.

[BawdyAnarchist]

One thing I'm not clear on, is which xpra socket should be exposed/shared between jail and host. Inside the jail, xpra start :100 creates no less than 3 sockets:

~/.xpra/<jail>-100
/tmp/.X11-unix/X100
/tmp/xpra/100/socket

FreeBSD does not allow nullfs mount (bind) for a socket. Directories and files only.
EDIT: I did try xpra start :100 --socket-dir=<shared_dir_between_host_and_jail> but I'm still having problems when trying to attach the host to it: xpra attach :100 --socket-dir=<shared_dir_between_host_and_jail>.

Another issue is that I need to be able to automate the starting of X11 applications, without asking the user to change their behavior depending on whether it's an X11 dependent command being sent to the jail or not. This is the reason why I wanted to set the environment (ideally from an rc file).

Is it a requirement that all applications be started with the xpra wrapper (due to security, or breaking the application display)? Or is it just that I'm losing some additional functionality?

[totaam]

creates no less than 3 sockets

It creates as many sockets as it can in all of the socket-dirs with bind=auto.
Alternatively, create just the one you need with --bind=/path/to/your/socket

but I'm still having problems when trying to attach the host to it

Try xpra attach socket://path/to/the/socket (not the directory)
socket-dir might not work if the hostname is not the same inside and outside the jail.

Is it a requirement that all applications be started with the xpra wrapper (due to security, or breaking the application display)?

To get the correct environment: dbus, pulseaudio, input devices, etc..

[BawdyAnarchist]

Just wanted to stop by, say thanks. This worked. I thought it was interesting that I was able to attach to either socket for the xpra server in the jail and it still worked:
/<jailpath>/tmp/xpra/101/socket
/<jailpath>$HOME/.xpra/<jail>-<socket_number>

I was actually able to use --socket-dir from the host, with a different hostname and a different relative path from what the jail sees, and it seemed to work fine, but I'll stick with socket: just in case.

I handle audio via a different mechanism, and input devices, browsing, video seemed to work fine without the specific --start mechanism. To keep the implementation simpler, I'll probably leave that out unless I'm experiencing problems.

If I do have broken input devices or problems related to dbus inside a jail, I'll consider that to be my error, and fix the xpra implementation before asking here.