Bugzilla – Bug 1217118
AUDIT-FIND: udev: DRM render nodes are world-writable
Last modified: 2023-12-13 09:30:09 UTC
DRM render nodes [1] are world-writable, as defined in `/usr/lib/udev/rules.d/50-udev-default.rules`. > crw-rw-rw- 1 root render 226, 128 Nov 2 09:36 /dev/dri/renderD128 Render nodes provide an interface for unprivileged GPU operations such as video encoding or offscreen rendering. The loose permissions mean that every system user, even `nobody`, can access the GPU drivers, cause load and potentially exploit hypothetical driver bugs. Although this configuration does NOT represent a security vulnerability, it does increase a local attack surface unnecessarily. I suggest following Debian's example and changing the permissions like this: `crw-rw---- root:render`, along with a uaccess ACL that grants access to all logged-in users. [1] https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#render-nodes
It sounds reasonable but I'm not of its consequences. Fabian, could you share your opinion ?
0666 is actually the upstream default, same for /dev/kvm: https://github.com/systemd/systemd/blob/a3f5976ded023257f6299ca07b9749fd1483c0d2/meson_options.txt#L313 uaccess would be enough to allow the usual use through logged in users and applications, would however break GPU acceleration through su to another user, ssh or libvirt virtio-gpu OOTB.
(In reply to Fabian Vogt from comment #3) > uaccess would be enough to allow the usual use through logged in users and > applications, would however break GPU acceleration through su to another > user, ssh or libvirt virtio-gpu OOTB. Are these use cases common enough or can we assume that users should rely on the "render" group when needed ?
(In reply to Franck Bui from comment #4) > (In reply to Fabian Vogt from comment #3) > > uaccess would be enough to allow the usual use through logged in users and > > applications, would however break GPU acceleration through su to another > > user, ssh or libvirt virtio-gpu OOTB. > > Are these use cases common enough or can we assume that users should rely on > the "render" group when needed ? Worth a try. If it breaks too much, it can be changed back again. IMO it should be documented at least and in the case of TW also announced.
+1 for giving it a try. The "render" group already exists and uaccess should be automatically configured when GROUP_RENDER_MODE != 666, so it seems that the upstream has considered this as a viable option. https://github.com/systemd/systemd/blob/a3f5976ded023257f6299ca07b9749fd1483c0d2/meson.build#L944 (In reply to Fabian Vogt from comment #3) > uaccess would be enough to allow the usual use through logged in users and > applications, would however break GPU acceleration through su to another > user, ssh or libvirt virtio-gpu OOTB. Valid point that must be considered. (In reply to Franck Bui from comment #4) > Are these use cases common enough or can we assume that users should rely on > the "render" group when needed ? Yes, IMHO it is not unreasonable to ask for `render` group membership for these less common use cases, as long as it is communicated reasonably well. There aren't many world-writable device nodes in /dev and given the complexity of graphics drivers, it makes sense to follow the principle of least privilege.
FYI https://build.opensuse.org/request/show/1128161 has been accepted and submitted to Factory: sr#1130178 Hence I'm closing the bug. Wolfgang can you please open another bug report for the documentation part ? Thanks.
This is an autogenerated message for OBS integration: This bug (1217118) was mentioned in https://build.opensuse.org/request/show/1130178 Factory / systemd