Bug 34592 - Dangerous /dev/dri/* permissions!
Summary: Dangerous /dev/dri/* permissions!
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-03 23:25 UTC by Chris Evans
Modified: 2007-04-18 16:32 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-07 05:01:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Chris Evans 2001-04-03 23:25:21 UTC
This is with the latest release at time of writing:
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.

Comment 1 Mike A. Harris 2001-04-05 06:16:30 UTC
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?

Comment 2 Chris Evans 2001-04-05 20:57:44 UTC
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.

Comment 3 Mike A. Harris 2001-05-25 11:36:53 UTC
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.

Comment 4 Mike A. Harris 2002-01-25 07:34:56 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.