xserver policy

xserver policy

[Russell Coker]

type_transition user_t xserver_exec_t:process xserver_t;
type_transition user_wm_t mono_exec_t:process mono_t;
type_transition user_wm_t wine_exec_t:process wine_t;
type_transition user_wm_t xserver_exec_t:process xserver_t;

Currently in the Debian SE Linux policy (which I believe to be identical to 
upstream refpolicy in this regard) the above are the possible transitions from 
user_t to unconfined domains.

The mono and wine modules can be removed for essentially identical 
functionality if you happen to not use mono or wine.

Both GNOME and KDE are dropping support for X11.  If we don't drop policy 
support for X11 I think we should at least separate xdm and xserver into 
separate modules so you can have XDM for Wayland without having an unconfined 
X server policy.  As an aside the current situation is that if you remove the 
unconfined module it will be impossible to login with any XDM program.

There is also an issue of xdm_t being unconfined, I'm working on a patch to 
fix that, I have a test machine with confined xdm_t working well.


Below is the list of unconfined domains:

$ seinfo -a unconfined_domain_type -x

Type Attributes: 1
   attribute unconfined_domain_type;
	apt_t
	dpkg_script_t
	dpkg_t
	httpd_unconfined_script_t
	inetd_child_t
	init_t
	initrc_t
	kernel_t
	ldconfig_t
	mono_t
	nagios_unconfined_plugin_t
	prelink_t
	puppet_t
	samba_unconfined_script_t
	spc_t
	spc_user_t
	unconfined_execmem_t
	unconfined_java_t
	unconfined_mount_t
	unconfined_munin_plugin_t
	unconfined_qemu_t
	unconfined_sendmail_t
	unconfined_t
	wine_t
	xdm_t
	xserver_t

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: xserver policy

[Christopher J. PeBenito]

On 5/5/26 9:03 AM, Russell Coker wrote:
> type_transition user_t xserver_exec_t:process xserver_t;
> type_transition user_wm_t mono_exec_t:process mono_t;
> type_transition user_wm_t wine_exec_t:process wine_t;
> type_transition user_wm_t xserver_exec_t:process xserver_t;
>
> Currently in the Debian SE Linux policy (which I believe to be identical to
> upstream refpolicy in this regard) the above are the possible transitions from
> user_t to unconfined domains.
>
> The mono and wine modules can be removed for essentially identical
> functionality if you happen to not use mono or wine.
>
> Both GNOME and KDE are dropping support for X11.  If we don't drop policy
> support for X11 I think we should at least separate xdm and xserver into
> separate modules
I have no objections to this. There has been some work from the Gentoo 
team on a wayland policy too, but I'm unsure what state it is in (it's 
upstreamed).
>   so you can have XDM for Wayland without having an unconfined
> X server policy.  As an aside the current situation is that if you remove the
> unconfined module it will be impossible to login with any XDM program.
Thanks for looking into this. I didn't realize a confined xdm was having 
issues.

-- 
Chris PeBenito

Re: xserver policy

[Russell Coker]

On Tuesday, 5 May 2026 23:56:57 AEST Christopher J. PeBenito wrote:
> > Both GNOME and KDE are dropping support for X11.  If we don't drop policy
> > support for X11 I think we should at least separate xdm and xserver into
> > separate modules
> 
> I have no objections to this. There has been some work from the Gentoo
> team on a wayland policy too, but I'm unsure what state it is in (it's
> upstreamed).

Are you saying we should remove the X server policy or just move xdm_t to a 
different module?

I'd prefer to remove X11 support.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: xserver policy

[Rahul Sandhu]

Hey,

As for the Wayland policy module, I've been looking into various compositors on
other desktops to see how they function and what they need. xdg-desktop-portal
specifically has given me a bit of grief whilst designing, and many of the big
desktop environments make use of it.

As for xdm_t specifically, I have been looking into that myself. Russell makes
a good point about the xserver module being required for a lot of things that
are not really related (e.g. fonts and mesa labelling iirc).

I've been playing around with greetd at present as it's small enough that it
should be a good login manager (that's the "new" term) to design with. It is
also noteworthy that plasma has a new login manager in the works too which is
a fork of sddm, so that might provide some opportunity for design there too.

However, I would personally be opposed against dropping xserver entirely, at
least for now. There are still a couple desktops using it, and I think this is
something that should be taken with caution. However, dropping XACE support if
it adds significant complexity seems reasonable to me right now.

The other thing to consider is Xwayland. I don't personally use it (or Xorg) 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 some bits that we
can share between a future xwayland_t and xserver_t, although that may turn out
to be a fruitless endeavour, I'm not entirely sure what Xwayland entails yet.

-- 
Rahul Sandhu

Re: xserver policy

[Russell Coker]

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 Xorg)
> 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 some
> bits that we can share between a future xwayland_t and xserver_t, although
> that may turn out to be a fruitless endeavour, I'm not entirely sure what
> Xwayland entails yet.

Currently Xwayland is running without any domain transition and works fine in 
user_t, what do you think we need to do in addition to this?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: xserver policy

[Rahul Sandhu]

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 Xorg)
>> 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 some
>> bits that we can share between a future xwayland_t and xserver_t, although
>> that may turn out to be a fruitless endeavour, I'm not entirely sure what
>> Xwayland entails yet.
>
> Currently Xwayland is running without any domain transition and works fine in 
> 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 Gentoo
side of things, so I'll submit something upstream when it's of decent quality.

Xwayland has a fair amount of attack surface and the codebase it's a part of
(Xorg) has a poor security record in the past. Also, whilst most compositors
run Xwayland rootless now (either via doing it directly like say wlroots does
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 the
"modern" Wayland desktop are both security critical targets that function as
a security boundry of some kind while also being reasonably modular such that
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 situation
is not the best for them, as the entire document portal has all documents as
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 as
previous efforts to do as such have resulted in deadlocks.

-- 
Rahul Sandhu

Re: xserver policy

[Christopher J. PeBenito]

On 5/5/26 11:49 PM, Russell Coker wrote:
> On Tuesday, 5 May 2026 23:56:57 AEST Christopher J. PeBenito wrote:
>>> Both GNOME and KDE are dropping support for X11.  If we don't drop policy
>>> support for X11 I think we should at least separate xdm and xserver into
>>> separate modules
>> I have no objections to this. There has been some work from the Gentoo
>> team on a wayland policy too, but I'm unsure what state it is in (it's
>> upstreamed).
> Are you saying we should remove the X server policy or just move xdm_t to a
> different module?
>
> I'd prefer to remove X11 support.

Separate xdm to a different module. I don't think X11/xserver rules 
should be dropped yet.

-- 
Chris PeBenito

Re: xserver policy

[Russell Coker]

On Thursday, 7 May 2026 04:17:46 AEST Christopher J. PeBenito wrote:
> > Are you saying we should remove the X server policy or just move xdm_t to
> > a
> > different module?
> > 
> > I'd prefer to remove X11 support.
> 
> Separate xdm to a different module. I don't think X11/xserver rules
> should be dropped yet.

OK I'll send a PR for making xdm_t a confined domain and after that one to put 
it in a separate module.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

xserver policy

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

I have attached an experimental patch for the X server policy that removes 
/dev/*mem access and some capabilities that aren't necessary when using a 
frame-buffer.

Strangely the X server seems to need sys_rawio even when using the frame 
buffer (X will abort if it can't get that access).  This may be a bug in the 
X server (I'm using XFree86 version 4.2.1).

Also I removed every_domain().

Finally I have been considering creating a separate domain for the SUID 
wrapper program, which would allow removing setuid and setgid capabilities 
from the main X server program (and possibly other access as well).

This is still a work in progress, the concept is good although the 
implementation is a bit rough.


Finally I suggest that the Frame Buffer device be the recommeded way of doing 
graphics on SE Linux as it allows you to really reduce the access that the X 
server geets to the system.  With sys_rawio it should still be possible to 
take over the system, but with memory_device_t it's just too easy to go from 
finding a bug in the X server to exploiting it.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[-- Attachment #2: xserver.diff --]
[-- Type: text/x-diff, Size: 1357 bytes --]

diff -ru /usr/share/selinux/policy/default/macros/program/xserver_macros.te /usr/share/selinux/policy/current/macros/program/xserver_macros.te
--- /usr/share/selinux/policy/default/macros/program/xserver_macros.te	2003-02-21 10:07:14.000000000 +0100
+++ /usr/share/selinux/policy/current/macros/program/xserver_macros.te	2003-02-24 12:11:44.000000000 +0100
@@ -37,12 +37,21 @@
 role $1_r types $1_xserver_t;
 ')dnl
 
-# This domain is granted permissions common to most domains (includes can_net)
-every_domain($1_xserver_t)
+uses_shlib($1_xserver_t)
+can_network($1_xserver_t)
+
+# for access within the domain
+general_domain_access($1_xserver_t)
+
+# for access to lots of base files
+general_file_read_access($1_xserver_t)
+
+allow $1_xserver_t proc_t:dir search;
 
 # Use capabilities.  Access /dev/mem.  
-allow $1_xserver_t self:capability { net_bind_service setuid setgid chown dac_override fsetid sys_rawio sys_admin sys_nice sys_tty_config };
-allow $1_xserver_t memory_device_t:chr_file { rw_file_perms execute };
+allow $1_xserver_t self:capability { setuid setgid sys_rawio sys_nice };
+dontaudit $1_xserver_t self:capability { dac_override dac_read_search };
+#allow $1_xserver_t memory_device_t:chr_file { rw_file_perms execute };
 
 allow $1_xserver_t mtrr_device_t:file rw_file_perms;
 allow $1_xserver_t apm_bios_t:chr_file rw_file_perms;