Bug 34592

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.