Bug 1217118

Summary:	AUDIT-FIND: udev: DRM render nodes are world-writable
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Wolfgang Frisch <wolfgang.frisch>
Component:	Security	Assignee:	systemd maintainers <systemd-maintainers>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Minor
Priority:	P4 - Low	CC:	fbui, fvogt, wolfgang.frisch
Version:	Current
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Wolfgang Frisch 2023-11-14 08:54:20 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

Comment 2 Franck Bui 2023-11-17 08:32:34 UTC

It sounds reasonable but I'm not of its consequences.

Fabian, could you share your opinion ?

Comment 3 Fabian Vogt 2023-11-20 09:45:34 UTC

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.

Comment 4 Franck Bui 2023-11-20 10:47:39 UTC

(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 ?

Comment 5 Fabian Vogt 2023-11-20 11:36:34 UTC

(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.

Comment 6 Wolfgang Frisch 2023-11-21 10:09:51 UTC

+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.

Comment 10 Franck Bui 2023-12-01 09:54:22 UTC

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.

Comment 11 OBSbugzilla Bot 2023-12-01 10:25:02 UTC

This is an autogenerated message for OBS integration:
This bug (1217118) was mentioned in
https://build.opensuse.org/request/show/1130178 Factory / systemd