Tighten permissions for DRM render nodes (/dev/dri/renderD128)
Hi, DRM render nodes [1] provide an interface for unprivileged GPU operations such as video encoding or off-screen rendering. They are currently world-writable in Factory:
crw-rw-rw- root:render /dev/dri/renderD128
This configuration allows every user, even `nobody`, to access the GPU drivers, cause load on the hardware and exploit hypothetical driver bugs. To our *current knowledge* this does not represent a security vulnerability. But given enough time and energy it very well might. It certainly does increase a local attack surface unnecessarily. Given the complexity of graphics drivers, maintaining such open permissions seems imprudent. While mode 0666 is the default [2], upstream has also been supporting an alternative configuration with mode 0660 and uaccess ACLs [3]. For context, here's how other distributions manage this:
Debian: mode 660 with uaccess Ubuntu: mode 660 with uaccess Fedora: mode 666
A submission [4] is underway to switch openSUSE Factory to this alternative configuration. This will result in Factory having these permissions:
crw-rw----+ root:render /dev/dri/renderD128
The impact of this change is likely to be zero for most users. If you have any workloads that depend on unprivileged GPU operations, you can simply add your user to the `render` group. Specific scenarios include: - Remote GPU access via ssh - Local GPU access by non-interactive users that aren't part of the render group yet, e.g. system users, cron jobs or `su` to another user. Best regards Wolfgang [1] https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#render-nodes [2] https://github.com/systemd/systemd/blob/a3f5976ded023257f6299ca07b9749fd1483... [3] https://github.com/systemd/systemd/blob/a3f5976ded023257f6299ca07b9749fd1483... [4] https://build.opensuse.org/request/show/1128161 -- Wolfgang Frisch <wolfgang.frisch@suse.com> Security Engineer OpenPGP fingerprint: A2E6 B7D4 53E9 544F BC13 D26B D9B3 56BD 4D4A 2D15 SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
On 11/22/23 16:59, Wolfgang Frisch wrote:
The impact of this change is likely to be zero for most users.
If you have any workloads that depend on unprivileged GPU operations, you can simply add your user to the `render` group. Specific scenarios include: - Remote GPU access via ssh - Local GPU access by non-interactive users that aren't part of the render group yet, e.g. system users, cron jobs or `su` to another user.
Is anyone aware of any unacceptable consequences of this change that may have been missed, or scenarios that should be tested beforehand? If not, the change can be applied IMHO. -- Wolfgang Frisch <wolfgang.frisch@suse.com> Security Engineer OpenPGP fingerprint: A2E6 B7D4 53E9 544F BC13 D26B D9B3 56BD 4D4A 2D15 SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg
Hi Am 29.11.23 um 17:18 schrieb Wolfgang Frisch:
On 11/22/23 16:59, Wolfgang Frisch wrote:
The impact of this change is likely to be zero for most users.
If you have any workloads that depend on unprivileged GPU operations, you can simply add your user to the `render` group. Specific scenarios include: - Remote GPU access via ssh - Local GPU access by non-interactive users that aren't part of the render group yet, e.g. system users, cron jobs or `su` to another user.
Is anyone aware of any unacceptable consequences of this change that may have been missed, or scenarios that should be tested beforehand?
ls -l /dev/dri says crw-rw----+ 1 root video 226, 1 30. Nov 07:20 card1 crw-rw-rw- 1 root render 226, 128 30. Nov 07:20 renderD128 If neither file is accessible by arbitrary users, how do they render graphics then? Best regards Thomas
If not, the change can be applied IMHO.
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Hi, On 11/30/23 07:49, Thomas Zimmermann wrote:
Am 29.11.23 um 17:18 schrieb Wolfgang Frisch:
Is anyone aware of any unacceptable consequences of this change that may have been missed, or scenarios that should be tested beforehand?
ls -l /dev/dri says
crw-rw----+ 1 root video 226, 1 30. Nov 07:20 card1 crw-rw-rw- 1 root render 226, 128 30. Nov 07:20 renderD128
If neither file is accessible by arbitrary users, how do they render graphics then?
udev applies the `uaccess` tag, which, in coordination with systemd-logind, dynamically applies an ACL granting access to all locally logged-in users. The end result looks like this: ``` localuser@localhost:/dev/dri$ ls -l total 0 drwxr-xr-x 2 root root 80 Nov 27 09:26 by-path crw-rw----+ 1 root video 226, 0 Nov 27 09:26 card0 crw-rw----+ 1 root render 226, 128 Nov 27 09:26 renderD128 localuser@localhost:/dev/dri$ getfacl renderD128 # file: renderD128 # owner: root # group: render user::rw- user:localuser:rw- group::rw- mask::rw- other::--- ``` All the best Wolfgang
-- Wolfgang Frisch <wolfgang.frisch@suse.com> Security Engineer OpenPGP fingerprint: A2E6 B7D4 53E9 544F BC13 D26B D9B3 56BD 4D4A 2D15 SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg
Hi Am 30.11.23 um 08:53 schrieb Wolfgang Frisch:
Hi,
On 11/30/23 07:49, Thomas Zimmermann wrote:
Am 29.11.23 um 17:18 schrieb Wolfgang Frisch:
Is anyone aware of any unacceptable consequences of this change that may have been missed, or scenarios that should be tested beforehand?
ls -l /dev/dri says
crw-rw----+ 1 root video 226, 1 30. Nov 07:20 card1 crw-rw-rw- 1 root render 226, 128 30. Nov 07:20 renderD128
If neither file is accessible by arbitrary users, how do they render graphics then?
udev applies the `uaccess` tag, which, in coordination with systemd-logind, dynamically applies an ACL granting access to all locally logged-in users. The end result looks like this:
OK, then ignore my other email. Thanks for the update. Best regards Thomas
``` localuser@localhost:/dev/dri$ ls -l total 0 drwxr-xr-x 2 root root 80 Nov 27 09:26 by-path crw-rw----+ 1 root video 226, 0 Nov 27 09:26 card0 crw-rw----+ 1 root render 226, 128 Nov 27 09:26 renderD128
localuser@localhost:/dev/dri$ getfacl renderD128 # file: renderD128 # owner: root # group: render user::rw- user:localuser:rw- group::rw- mask::rw- other::--- ```
All the best Wolfgang
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Am 30.11.23 um 07:49 schrieb Thomas Zimmermann via openSUSE Factory:
Hi
Am 29.11.23 um 17:18 schrieb Wolfgang Frisch:
On 11/22/23 16:59, Wolfgang Frisch wrote:
The impact of this change is likely to be zero for most users.
If you have any workloads that depend on unprivileged GPU operations, you can simply add your user to the `render` group. Specific scenarios include: - Remote GPU access via ssh - Local GPU access by non-interactive users that aren't part of the render group yet, e.g. system users, cron jobs or `su` to another user.
Is anyone aware of any unacceptable consequences of this change that may have been missed, or scenarios that should be tested beforehand?
ls -l /dev/dri says
crw-rw----+ 1 root video 226, 1 30. Nov 07:20 card1 crw-rw-rw- 1 root render 226, 128 30. Nov 07:20 renderD128
If neither file is accessible by arbitrary users, how do they render graphics then?
To answer my question: I just did sudo chmod 660 /dev/dri/renderD128 to clear the permissions for others. ls -l /dev/dri/ crw-rw----+ 1 root video 226, 1 30. Nov 07:20 card1 crw-rw---- 1 root render 226, 128 30. Nov 07:20 renderD128 Running glxinfo now reports the llvmpipe backend, which is the software renderer. OpenGL vendor string: Mesa OpenGL renderer string: llvmpipe (LLVM 17.0.5, 256 bits) OpenGL core profile version string: 4.5 (Core Profile) Mesa 23.2.1 OpenGL core profile shading language version string: 4.50 Hardware acceleration is now disabled for users that are not in the video or render groups. I like the idea of limiting access to /dev/dri/ files, but it still needs to work for regular users out of the box. Here is the output of groups users games disk dialout osc Is it possible to automatically add everyone in group 'users' to 'render' as well? Best regards Thomas
Best regards Thomas
If not, the change can be applied IMHO.
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
On Thursday 2023-11-30 09:13, Thomas Zimmermann via openSUSE Factory wrote:
Here is the output of groups
users games disk dialout osc
Is it possible to automatically add everyone in group 'users' to 'render' as well?
No, but at that point why don't you just augment udev to add an ACE to the device node for g:users?
Hi, On Thu, Nov 30, 2023 at 09:13:59AM +0100, Thomas Zimmermann via openSUSE Factory wrote:
Am 30.11.23 um 07:49 schrieb Thomas Zimmermann via openSUSE Factory:
Hi
Am 29.11.23 um 17:18 schrieb Wolfgang Frisch:
On 11/22/23 16:59, Wolfgang Frisch wrote:
The impact of this change is likely to be zero for most users.
If you have any workloads that depend on unprivileged GPU operations, you can simply add your user to the `render` group. Specific scenarios include: - Remote GPU access via ssh - Local GPU access by non-interactive users that aren't part of the render group yet, e.g. system users, cron jobs or `su` to another user.
Is anyone aware of any unacceptable consequences of this change that may have been missed, or scenarios that should be tested beforehand?
ls -l /dev/dri says
crw-rw----+ 1 root video 226, 1 30. Nov 07:20 card1 crw-rw-rw- 1 root render 226, 128 30. Nov 07:20 renderD128
If neither file is accessible by arbitrary users, how do they render graphics then?
To answer my question: I just did
sudo chmod 660 /dev/dri/renderD128
to clear the permissions for others.
ls -l /dev/dri/
crw-rw----+ 1 root video 226, 1 30. Nov 07:20 card1 crw-rw---- 1 root render 226, 128 30. Nov 07:20 renderD128
Running glxinfo now reports the llvmpipe backend, which is the software renderer.
OpenGL vendor string: Mesa OpenGL renderer string: llvmpipe (LLVM 17.0.5, 256 bits) OpenGL core profile version string: 4.5 (Core Profile) Mesa 23.2.1 OpenGL core profile shading language version string: 4.50
Hardware acceleration is now disabled for users that are not in the video or render groups. I like the idea of limiting access to /dev/dri/ files, but it still needs to work for regular users out of the box.
Here is the output of groups
users games disk dialout osc
Is it possible to automatically add everyone in group 'users' to 'render' as well?
In general the hope was that it would still work if the renderD128 device is created using udev and using uaccess rules. I think the main problem with uaccess was / is that NVIDIA binary-only-drivers will not set uaccess permissions, as this is a GPL interface.
Best regards Thomas
Best regards Thomas
If not, the change can be applied IMHO.
Ciao, Marcus
On 12/1/23 13:06, Marcus Meissner wrote:
I think the main problem with uaccess was / is that NVIDIA binary-only-drivers will not set uaccess permissions, as this is a GPL interface.
Thank you for this legitimate concern. Fortunately, this problem appears to be a thing of the past. I just booted a system with the proprietary NVIDIA driver and the modified udev package, and the permissions are set correctly: $ glxinfo |grep "OpenGL vendor" OpenGL vendor string: NVIDIA Corporation $ ls -l /dev/dri/ total 0 drwxr-xr-x 2 root root 120 Dec 7 10:42 by-path crw-rw----+ 1 root video 226, 0 Dec 7 10:42 card0 crw-rw----+ 1 root video 226, 1 Dec 7 10:42 card1 crw-rw----+ 1 root render 226, 128 Dec 7 10:42 renderD128 crw-rw----+ 1 root render 226, 129 Dec 7 10:42 renderD129 All good :) -- Wolfgang Frisch <wolfgang.frisch@suse.com> Security Engineer OpenPGP fingerprint: A2E6 B7D4 53E9 544F BC13 D26B D9B3 56BD 4D4A 2D15 SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg
On Thu, Dec 07, 2023 at 10:50:04AM +0100, Wolfgang Frisch wrote:
On 12/1/23 13:06, Marcus Meissner wrote:
I think the main problem with uaccess was / is that NVIDIA binary-only-drivers will not set uaccess permissions, as this is a GPL interface.
Thank you for this legitimate concern. Fortunately, this problem appears to be a thing of the past. I just booted a system with the proprietary NVIDIA driver and the modified udev package, and the permissions are set correctly:
$ glxinfo |grep "OpenGL vendor" OpenGL vendor string: NVIDIA Corporation
$ ls -l /dev/dri/ total 0 drwxr-xr-x 2 root root 120 Dec 7 10:42 by-path crw-rw----+ 1 root video 226, 0 Dec 7 10:42 card0 crw-rw----+ 1 root video 226, 1 Dec 7 10:42 card1 crw-rw----+ 1 root render 226, 128 Dec 7 10:42 renderD128 crw-rw----+ 1 root render 226, 129 Dec 7 10:42 renderD129
All good :)
Well, what you need to do is a getfacl on the devices. Then you'll see, that the user who is logged in to a graphical session, has permissions to read/write to it not matter in which group he is. Thanks to the magic we're doing in our packages. Thanks to the hints [1] Franck gave me ... [1] boo#1000625, comments#36-#43 CU, Stefan Public Key available ------------------------------------------------------ Stefan Dirsch (Res. & Dev.) SUSE Software Solutions Germany GmbH Tel: 0911-740 53 0 Frankenstraße 146 FAX: 0911-740 53 479 D-90461 Nürnberg http://www.suse.de Germany ---------------------------------------------------------------- Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman (HRB 36809, AG Nürnberg) ----------------------------------------------------------------
On 11/22/23 16:59, Wolfgang Frisch wrote:
Hi,
DRM render nodes [1] provide an interface for unprivileged GPU operations such as video encoding or off-screen rendering. They are currently world-writable in Factory:
crw-rw-rw- root:render /dev/dri/renderD128
This configuration allows every user, even `nobody`, to access the GPU drivers, cause load on the hardware and exploit hypothetical driver bugs. To our *current knowledge* this does not represent a security vulnerability. But given enough time and energy it very well might. It certainly does increase a local attack surface unnecessarily. Given the complexity of graphics drivers, maintaining such open permissions seems imprudent.
While mode 0666 is the default [2], upstream has also been supporting an alternative configuration with mode 0660 and uaccess ACLs [3]. For context, here's how other distributions manage this:
Debian: mode 660 with uaccess Ubuntu: mode 660 with uaccess Fedora: mode 666
A submission [4] is underway to switch openSUSE Factory to this alternative configuration. This will result in Factory having these permissions:
crw-rw----+ root:render /dev/dri/renderD128
The impact of this change is likely to be zero for most users.
If you have any workloads that depend on unprivileged GPU operations, you can simply add your user to the `render` group. Specific scenarios include: - Remote GPU access via ssh - Local GPU access by non-interactive users that aren't part of the render group yet, e.g. system users, cron jobs or `su` to another user.
Another use case, as I found out, is using the GPU in a docker container. In my case it is ffmpeg making use of QSV and VA-API for hardware transcoding. If the docker container is running under an unprivileged user (either a private user declared in the Dockerfile with the USER directive or an existing host user other than root passed with the -u docker option), access to /dev/dri/renderD128 in the container must be granted, passing the numeric group value of the 'render' host group with the --group-add option (here using getent to get the numeric value): docker run ... --device /dev/dri:/dev/dri --group-add $(getent group render | cut -d ':' -f 3) ...
participants (6)
-
Jan Engelhardt -
Marcus Meissner -
Michael Pujos -
Stefan Dirsch -
Thomas Zimmermann -
Wolfgang Frisch