Nested Xorg for GUI Isolation?

[0xc1c4da]

It appears in quBSD relies on X11 forwarding over a unix socket to nullfs which is a security issue in terms of GUI Isolation, and as @BawdyAnarchist has documented here.

In lieu of implementing vchan for Bhyve inter-vm communication or similarly for inter-jail communication, have you considered a Nested Xorg solution?

Its suggested by Subgraph, or in Firejail here and in the Firejail Arch Wiki, which recommends using Xpra or Xephr?

Xephr seems to be the preferred approach, also adopted by SELinux , and is considered in Qubes as the hybrid gui domain aka the compromise solution.

Xephr can be resizable, and use GL acceleration (through Glamor), however X11R7.8 suggests replacing Xephr with xf86-video-dummy and xf86-video-nested DDX drivers, although I haven't found much documentation on them. I also found xf86-video-ephyr which is xf86-video-nested based directly on Xephr, which could be interesting.

[0xc1c4da]

Another approach is to ditch X entirely and setup a desktop based on Wayland as they have solved a lot of these GUI Isolation problems. It seems Wayland runs over a unix socket , should be fairly drop in to the existing architecture?

Clients (Wayland Apps) do their own rendering, meaning that for performance, the gpu may need to be exposed to the jail. That would entail sacrificing GPU IOMMU security or forcing software rendering. Alternatively, Waypipe might be an attractive option, or I might investigate VirtualGL's applicability to Wayland.

For the Nest Compositor approach, there's Sommelier, a nested Wayland Compositor that is also capable of doing X11 Forwarding (with XWayland). It can run over a socket. However it does not have a FreeBSD Port.

There is also an approach to isolating XWayland here as well as the author's own version of Sommelier, wayland-proxy-virtwl, but seems to be dependent on crosvm, because it has a driver that allows forwarding Wayland connections

[BawdyAnarchist]

Hi @0xc1c4da 0xc1c4da I just wanted to say thanks for all of the suggestions. It's going to take me some time to work though some of these. I've stalled in development for the past few months, and I'm not sure that I'll be able to spend much time on quBSD.

But I'm definitely going to look at the GUI ideas and resources you sent. That unix socket is one of the most glaring deficiencies in my mind.