XDC2012: Graphics stack security
XDC2012: Graphics stack security
Posted Sep 26, 2012 23:43 UTC (Wed) by mupuf (subscriber, #86890)In reply to: XDC2012: Graphics stack security by dpquigl
Parent article: XDC2012: Graphics stack security
The point of the presentation wasn't to fix X, it was to fix DRM, to talk about security in Wayland and discuss about a security policy for it.
Posted Sep 27, 2012 0:15 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
While I expect that doing checks on these half dozen or so 'special' priviledges would break a few things, I don't think it would be that many, and if the capaibility was available, distros would experiment with them.
After all, we know that SELinux breaks things, but it's being deployed. I would expect that SELinux has broken far more things than a handful of permission checks in X would.
> The point of the presentation wasn't to fix X, it was to fix DRM
this writeup makes it sound like it was talking about problems in X not in the DRM layer.
Posted Sep 27, 2012 9:56 UTC (Thu)
by Siosm (subscriber, #86882)
[Link]
I don't think we will be able to fix the input problems in X.
> After all, we know that SELinux breaks things, but it's being deployed. I would expect that SELinux has broken far more things than a handful of permission checks in X would.
SELinux is mostly used in a "targeted" way in Red Hat/Fedora, and thus does not protect GUI apps. It is a lot of work to create and maintain an SELinux policy for every GUI applications.
> this writeup makes it sound like it was talking about problems in X not in the DRM layer.
The second talk deals with DRM problems. This one was done to recap known problems and make sure we do not do the same "mistakes" with Wayland/Weston
Posted Oct 1, 2012 4:33 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Most SELinux permissions checks happen where applications should already expect them to be occurring such as on filesystem objects. Putting in permissions where there weren't any before and where there is a lot of backwards compatibility requirements for very old software seems like a very bad idea and quite likely to break the world.
XDC2012: Graphics stack security
XDC2012: Graphics stack security
XDC2012: Graphics stack security