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
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
