Bug 108501 - XACE/XSEL XEXT: DRI3 clients need to read all x drawables
Summary: XACE/XSEL XEXT: DRI3 clients need to read all x drawables
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2018-10-19 17:58 UTC by dac.override
Modified: 2018-12-13 22:41 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description dac.override 2018-10-19 17:58:51 UTC
X clients that use DRI3 need have access to all xdrawables. This is not feasible because that would allow these clients to capture drawables of other X clients (do screenscraping)

XACE can be used to enforce fine-grained mandatory access control. If you disable any DRI3 user access to the root xdrawables, it will freeze the root xdrawable:

avc:  denied  { read } for request=DRI3:Open comm=/app/extra/vscode/code --type=gpu-process --disable-features=Co resid=155 restype=WINDOW scontext=wheel.id:wheel.role:flatpak.container.wheel.subj:s0 tcontext=wheel.id:object_r:xserver.root_xdrawable.xdrawable:s0 tclass=x_drawable permissive=0

In the example above a process "/app/extra/vscode/code" was requesting "DRI3:Open" , and this caused it to "read" the xserver root x_drawable. Without this access, this event would cause this x_drawable to freeze (and since that is the root xdrawable, basically your screen is frozen)

To reproduce this event just block access to the root x_drawable for any DRI3 process.

To make this easier to reproduce I have a Fedora Rawhide liveCD available that has a policy (almost ready to test). Be aware that this issue cannot reproduced on QEMU/QXL as that does not support DRI3 (supposedly).

URL to livecd to test:



Boot the liveCD (make sure you have enough memory allocated
Log in with: liveuser (no password)
sudo setsebool xserver_object_manager on (enable XACE)
sudo setsebool xserver.xace.enable_dri3_xextension off (turn off the boolean with bad access control rule that allows DRI3 user to read arbitrary xdrawables)
sudo semodule -DB (make selinux verbose)
sudo cat > mytest.cil <<EOF
(in xserver (call dri3_xextension.query_xextension (xace.client_subj_type_attribute))
(call dri3_xextension.use_xextension (xace.client_subj_type_attribute)))
sudo semodule -i mytest.cil
Above allows the subject to query and use the dri3 xextension
startx /usr/bin/awesome (start awesomewm)
SUPER+ENTER to open xterm
sudo dnf install rpm-plugin-selinux (this needs to be installed first, was a bug in rawhide at the time of livecd image compilation)
sudo dnf install flatpak (install flatpak because that is what is contained using XACE)
flatpak --user remote-add flathub --from https://flathub.org/repo/flathub.flatpakrepo (install the flathub repository)
flatpak --user install flathub com.visualstudio.code (this app is knows to use DRI3)
flatpak --user run com.visualstudio.code (not how this freezes your root xdrawable)
CTRL+ALT+F2 (turn to TTY)
journalctl -rb --grep denied | grep -i DRI3 (notice the AVC denial mentioned above

To see the rules associated with the xserver.xace.allow_dri3_xextension:
sesearch -A -b xserver.xace.allow_dri3_xextension

To confirm that it does work if it has access to xdrawables simple toggle the boolean to on and try again.

Video demo on YouTube using QEMU/QXL (so was unable to reproduce issue there but might give some pointers as to how to try this out)


Policy used:


Theres also a few other issues with XACE that are visible in this procedure:

Rootless Xserver tries to log to privileged audit but is not allowed due to missing CAP_AUDIT_WRITE
Comment 1 Uli Schlachter 2018-10-20 07:43:43 UTC
So, I tried to find the piece of code that does this access. I ended up here:


This looks up the passed-in drawable via dixLookupDrawable() with DixReadAccess. I guess this is where the XACE check is done.

The following code only uses the provided drawable to select a screen (it only uses 'drawable->pScreen' and no other members of drawable). Thus, I would guess that a client could just create a new window, then use that in DRI3Open and would then gain the same kind of access than what XACE is preventing here. (But I am not sure what kind of access that would be.)
Comment 2 GitLab Migration User 2018-12-13 22:41:05 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/550.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.