[rfc] VIA dri and security.

[Keith Whitwell]

Thomas Hellström wrote:
> Hi, Keith!
> 
> 
>>Thomas Hellström wrote:
>>
>>>Hi!
>>>
>>>Sorry for the double posting. This is a thing that needs to be discussed
>>>in both communities.
>>>
>>>The via DRM has started it's journey into the linus kernel, but the 3D
>>>driver / DDX still suffers
>>>from a security flaw:
>>>
>>>When the MMIO area is exported read-write it is assumed possible for a
>>>dri client to manipulate registers to
>>>blit otherwise protected areas of the system memory to video memory. It
>>>is the DDX that tells the DRM whether to export the MMIO area read-only
>>>or read-write. The OpenGL 3D driver unichrome_dri.so currently needs
>>>write access to this area, until someone fixes it up to use register
>>>writing ioctls now present in the via drm.
>>>
>>>The obvious fix is for the DDX to tell DRM to export the MMIO area as
>>>read-only. In this way a normal user would get a segfault when trying to
>>>run accelerated OpenGL, while it would work as root.
>>
>>
>>This sort of thing has been discussed in the past, going all the way back
>>to
>>UtahGLX, which had a root-only direct rendering system of sorts.
>>
>>The trouble with doing this, and this was well established in UtahGLX, is
>>that
>>if you make a high-performance path available only to root, you get people
>>running as root when they ordinarily wouldn't do so in order to access
>>that
>>performance path.  Specifically, you're encouraging people to run
>>binary-only
>>games & toys with full superuser permissions.
>>
>>This is actually worse than a DRM model with theoretical insecurities -
>>under
>>that model a program would have to be cleverly crafted to expose and
>>exploit
>>the insecurity.  Under this "run games as root" model, all of a sudden
>>games
>>have to be cleverly crafted and audited to *avoid* exposing
>>insecurities...
>>
>>Nobody has done a security audit on q3 that would allow you to feel
>>comfortable running it as root, to my knowledge...
>>
>>Keith
>>
> 
> 
> Agreed.
> 
> So what is your actual suggestion?
> Export read-write as default or, as proposed, export read-write when
> "AllowInsecureDRI" is enabled in the X server config?

To tell the truth, I wasn't making one.  If I were to though, it would follow 
on from the above fairly directly:

	- Don't allow any situation where root clients have better access to hardware 
than non-root clients.

So, to my mind that would mean

	1) Don't export insecure registers read-write, and
	2) Don't distribute anything until there exists a working non-root 3d driver.

That way there would be no incentive to run insecure programs as root.

It's clear that this circumstance wasn't considered by the original DRM 
designers, or there would be a way to create mappings that are private to the 
X server, so that not even root clients would be able to use them.

Note that this isn't about restricting the ability of root processes to damage 
the system, but rather about removing an incentive to run insecure programs as 
root.

Keith