fdo-mirrors/xserver
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/xorg/xserver.git synced 2025-12-20 03:30:04 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Create a SECURITY.md file

Browse source 
Provide information on where to report or learn of security bugs,
and what we do or do not consider to be a security bug.

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/2103>
This commit is contained in:
Alan Coopersmith 2025-11-18 17:08:39 -08:00
parent 0060b91b49
commit a5047d4a65
1 changed files with 50 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

50
SECURITY.md Normal file
View file

@ -0,0 +1,50 @@
# Reporting Security Issues
Please notify us of any security issues by sending mail to
<xorg-security@lists.x.org>.
See https://www.x.org/wiki/Development/Security/Organization/
for more information about the X.Org security team.
# Learning about Security Fixes
X.Org announces security bugs and bug fix releases on the xorg-announce
mailing list. See the archives at https://lists.x.org/archives/xorg-announce/
and see https://lists.x.org/mailman/listinfo/xorg-announce to subscribe.
Security advisories are also listed on our wiki at
https://www.x.org/wiki/Development/Security/ and mailed to the
https://oss-security.openwall.org/wiki/mailing-lists/oss-security mailing list.
# Security model and trust boundaries
Only the Xorg server is expected to run with elevated privileges.
(Some distros may run Xorg with a wrapper to only grant these privileges when
necessary.) The Xorg server usually requires root access to hardware devices
and I/O registers when using a UMS (Userspace Mode Setting) driver, and not
when using a KMS (Kernel Mode Setting) driver, or drivers which do not require
actual hardware access (such as xf86-video-dummy).
All other X servers (Xephyr, Xnest, Xvfb, etc.) are expected to run with only
the privileges of the user who started the server. They should not require
direct access to any devices.
The Xorg server uses configuration files to control various aspects of its
operation (see the xorg.conf(5) man page), including specifying loadable
object modules to run code from with the full privileges of the X server.
There is no attempt to sandbox these modules - they are considered to be fully
trusted, and thus anyone who can edit a config file is considered to be fully
trusted - a module being able to control or crash the X server is not considered
a security vulnerability (though a crash would be a non-security bug in the
module). The configuration file loading mechanism takes steps to verify that
config files are owned by trusted users before reading them, and failure to do
so would be considered a security vulnerability.
Access control for which clients can connect to the X server is provided by
a number of mechanisms, see the Xsecurity(7) man page for details. Once a
client is authenticated via those mechanisms and has an active connection,
we do not consider it a security vulnerability for them to be able to take
any actions described in the X11 protocol or extension specifications, such
as changing monitor configurations or killing other clients, though we will
accept non-security bug reports for clients doing so in a manner or via
requests not documented in the protocol specs as doing those operations.