On Wed, Jul 1, 2009 at 12:55 PM, Jesse Barnes<jbar...@virtuousgeek.org> wrote: > On Tue, 30 Jun 2009 23:43:19 -0700 > Eric Anholt <e...@anholt.net> wrote: > >> On Mon, 2009-06-29 at 16:52 -0700, Jesse Barnes wrote: >> > Just a DRM_MASTER flag is sufficient here, though maybe this call is >> > totally deprecated anyway (xf86-video-intel still calls it though). >> > >> > Signed-off-by: Jesse Barnes <jbar...@virtuousgeek.org> >> Acked-by: Eric Anholt <e...@anholt.net> > > We'll also need to do something about DRM_IOCTL_AUTH_MAGIC... is it > safe to make that master only?
I suppose. The auth concept is pretty fuzzy / watered out at this point, with dri2 and multiple drm masters. If you vt switch away from one X server to a different vt and auth with the X server there, you're equally authenticated with the first server and can access all its buffers if they have global names and you know those names. So making AUTH_MAGIC master only doesn't make it anything less secure, it just means that you can get auth directly instead of going through a setuid X server to get authenticated. Or I guess we could change the implementation to not just remember an auth bit, but also the master it auth'ed with. If we want to do better (and if we care about security enhanced X in a GEM world we do) we need something like an auth group. We'll want to support multiple groups active at the same time (that is, more flexible than the current drop/set master where only one is active at a time) and we'll want to support clients that are members of several groups at the same time. So, an auth group would be an X server and its direct rendering clients (or a wayland server). The server could in turn be a client of another server, for example for a secure nested containerized server under your normal desktop session or maybe your session server is a client of a system display server. Which is why Of course, the sticking point is that if we want to enforce this access control, we need to do it at the GEM level. We need to verify that the client has access to the buffers it uses (in all the ioctls that operate on a global name) and that the batch buffers doesn't contain references to absolute gart addresses that could reference buffer objects the client isn't authenticated to get at. Or just unbind/evict all buffers that client isn't allow to touch when it submits batch buffer. Changing AUTH_MAGIC to not require root doesn't compromise anything more than it currently is. We should probably track the master a file is auth'ed with and not just the file->authenticated bit. I suppose we can add the paranoid secure scheme later, if necessary, as an opt-in. If you want to run a "secure" X/wayland server, you create an auth group and all the buffers for that server and it's clients belong to that group. Those buffers get evicted when a non-authed client submits an execbuffer. So just make it a no-op, and make it not require root. cheers, Kristian ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
