This is with the latest release at time of writing: qa0401. . If I login to X, the following correct DRI permissions result: [chris@localhost chris]$ ls -l /dev/dri/* crw------- 1 chris root 10, 63 Apr 3 19:08 /dev/dri/card0 . Now, I log out. Unfortunately, insecure permisisons are adopted: chris@localhost chris]$ ls -l /dev/dri/* crw-rw-rw- 1 root root 10, 63 Apr 3 19:08 /dev/dri/card0 . I believe this to be an X bug. /etc/security/console.perms correctly wants to set the permissons to 0600. However I strongly suspect the X server is unlinking and recreating the device node with insecure permissions, thus thwarting the secure PAM console setup.
This topic came up a few months ago WRT DRI not being accessible to users by default. A user had to manually edit their X configuration file in order to enable DRI. This is extremely inconvenient. It was decided to have the DRI permissions default to 666 because it allows a console user to use DRI without fussing around. The DRI takes care of ensuring that nobody can muss with things by providing access mechanisms. These access mechanisms are currently believed to be safe. Are you aware of any exploitable security issues with having the DRI permissions set like this?
Yes, I logged the original bug :-) However, I didn't envisage this particular solution. And yes, I've seen what could be problems with the permissions -rw-rw-rw- (more on that below). Even if the absence of any specific problems, I would still want this fixed. Why? Because anything vaguely X related tends to be a bit of a nightmare with regards security. And recent work has nicely restricted X issues to console access, which is equivalent to being able to nick the machine anyway :) So, the fact that DRM device nodes are accessible to non-console users is a bit of a regression. We need to stop adding risks to the distribution, there are plenty enough already! . Onto possible solutions: 1) Use pam_console. This is already used, and partially works. The main problem is that X, when it restarts, likes to destroy and recreate the /dev/dri device nodes. I propose that X should only delete/recreate device nodes if the device details change. This is going to be a rare event. Also, to cater for users using "startx" rather than KDM or GDM, the /dev/dri/* ownerships will need to be granted to the <console> group rather than the <xconsole> 2) Use a variant of pam_console. I'm not sure if the current pam_console and associated stuff can do this, but if not it can always be enhanced! If the permissions are issued on the /dev/dri directory itself, X is free to create the /dev/dri/* nodes with whatever mode it likes. Unfortunately, we would need to set the _group_ not the _owner_ on /dev/dri, and I don't know if PAM can do that. The reason we don't want to give ownership is the issue of being able to create files and hardlinks etc. on the root filesystem. 3) Revert to X creating 0600 /dev/dri/* nodes. Thanks to PAM, KDM and GDM logins will give ownership properly. But, a disadvantage is that "startx" based X sessions will not have working DRI for non-root. . Onto the possible security issues - mmap() of DRM generic DMA buffer does not seem to be restricted. - ioctl() is lucky not to have a nasty security hole. They all almost have an integer signedness issue with the ioctl number being placed in a signed integer and used as an index into a function table.
Update: The XFree86 trunk code has a fix for this issue which from what I understand will be made available for 4.0.x as well in the near future.
I'm closing this bug now, as there are no known security holes in DRM. I'd rather see them fixed if they do come up however. We have released XFree86 4.1.0-15 for RHL 7.1 also.