Lots of RHEL servers do, but I would guess that selinux stops this exploit, I see no reason for X to have write permission in /etc.

Redhat ships with a targeted policy. Most of the non-network programs are put in a very permissive domain to avoid breakage.

I just checked the CentOS policy[0] (not at work and don't have easy access to the Redhat repos).

It appears that xserver_t does have write access to both etc_t and shadow_t [1].

More specifically, xserver_t is part of the selinux_unconfined_type attribute, which means that it can do pretty much anything. (Even more specifically, it is part of the files_unconfined_type attribute, which gives it write permissions to everything in file_type):

  > sesearch --allow -s xserver_t -t shadow_t -c file policy.31
  allow files_unconfined_type file_type:file execmod; [ selinuxuser_execmod ]:True
  allow files_unconfined_type file_type:file { append audit_access create execute execute_no_trans getattr ioctl link lock mounton open quotaon read relabelfrom relabelto rename setattr swapon unlink write };

[0] https://centos.pkgs.org/7/centos-updates-x86_64/selinux-poli...

[1] Because of its sensitive nature, /etc/shadow has its own SELinux label

Already been patched in any case.

https://gitlab.freedesktop.org/xorg/xserver/commit/50c0cf885...

Some people install Xorg on their servers because they need to render stuff (e.g. using OpenGL or Vulkan).

that's not needed at all, unless you have legacy applications.

you can open a dri render device node, and use it directly