On Fri, Jul 3, 2009 at 5:47 AM, Daniel Stone<dan...@fooishbar.org> wrote: > On Wed, Jul 01, 2009 at 09:39:17PM -0400, Kristian Høgsberg wrote: >> If we want to do better (and if we care about security enhanced X in a >> [... snipped for brevity ...] >> session server is a client of a system display server. Which is why > > ... ? :)
Yes, sorry, that got a little long and incoherent. I blame sleep deprivation :) There's a couple of valid points in there, though: 1) Yes, let's remove root requirement from DRM_IOCTL_AUTH_MAGIC. 2) DRM authentication is compromised by the dropMaster/setMaster ioctls used to support DRI capable X servers on multiple VTs. Authentication is a global flag on the filp, and isn't restricted to the resources provided by the authenticating master (X server). So a DRI client from one server can now get at the front buffer from another server. The rest of the mail is rambling about whether we care about this and if so ideas for solving it. The XACE work is trying "harden" the protocol to prevent clients from writing to the root window, reading out pixels from other windows etc. If we're serious about that effort, we need to think about a better authentication scheme since right now drm is a big back door to the protocol from the XACE point of view. Which resources are you authenticating to access, and how do we enforce that? The session / system display server is something I've started thinking about for wayland: in the case where you have several sessions, multi seat, fast user switching, or graphical vt's, native rdp clients, native qemu sessions, you'll want some process in charge of switching between those sessions. I'm calling that a system compositor, and it could be a wayland server... or an X server, I suppose. As a client of the system compositor, you have your GNOME session running in a nested X server or a Moblin session running under a nested wayland server or whatever. At that point you have two simultaneous authentication domains active and clients from the Moblin session should not be able to go peeking into the system compositors buffers. cheers, Kristian ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
