Re: xserver policy

On Wed May 6, 2026 at 9:50 AM BST, Russell Coker wrote:
> On Wednesday, 6 May 2026 18:17:33 AEST Rahul Sandhu wrote:
>> The other thing to consider is Xwayland. I don't personally use it (or X=
org)
>> at all myself, however I do know that some stuff still requires Xwayland
>> and it is very common as of 2026. It might be worth seeing if there is s=
ome
>> bits that we can share between a future xwayland_t and xserver_t, althou=
gh
>> that may turn out to be a fruitless endeavour, I'm not entirely sure wha=
t
>> Xwayland entails yet.
>
> Currently Xwayland is running without any domain transition and works fin=
e in=20
> user_t, what do you think we need to do in addition to this?


Ideally, we'd have an xwayland_t imo. I've been hacking on this on the Gent=
oo
side of things, so I'll submit something upstream when it's of decent quali=
ty.

Xwayland has a fair amount of attack surface and the codebase it's a part o=
f
(Xorg) has a poor security record in the past. Also, whilst most compositor=
s
run Xwayland rootless now (either via doing it directly like say wlroots do=
es
or using something like xwayland-satellite like numerous of the new smithay
compositors), there are still quite a few running it rootful. Hence, I am
personally of the opinion that it's a good target for a private domain.

Ideally, I'm looking to slowly get the major components of modern desktops,
such as the compositor and desktop tooling into some form of private domain=
.
Whilst it will be a lot less granular for more complex desktop environments
with a monolithic design (such as say Gnome), a lot of the components of th=
e
"modern" Wayland desktop are both security critical targets that function a=
s
a security boundry of some kind while also being reasonably modular such th=
at
a private domain is actually within the realm of possibility for them.

I'm also currently working quite a bit on the portals. The labelling situat=
ion
is not the best for them, as the entire document portal has all documents a=
s
fuse_t. This is because fuse is not a seclabelfs, something which I intent =
to
try and solve upstream in the kernel. This is however quite a bit of work a=
s
previous efforts to do as such have resulted in deadlocks.

--=20
Rahul Sandhu