On Thu, 2010-08-19 at 16:24 +0200, Christoph A. wrote: > Hi, > > I assumed sandboxed application run within there own embedded X server > instance (Xephyr) to protect Xorg against attacks originating from the > sandbox. My assumption seams to be wrong as the recent security issue > showed [1]. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2240 > > My question is: Why do sandboxed X application run within Xephyr? > Is the attack surface smaller if an application runs within Xephyr even > if Xephyr must be allowed to talk to Xorg? It prevents the client application from directly communicating with the top-level Xorg server. In the case of the bug you cited, they have to first escalate access and gain code execution within Xephyr before they can mount the attack on the top-level Xorg server, rather than being able to directly attack the top-level Xorg server from the client app. Curious as to whether they in fact wrote a successful exploit that did that, or just pointed out that it is theoretically possible. As far as SELinux is concerned, the Xephyr instance is running in sandbox_xserver_t rather than just xserver_t. So one could in theory use the XACE/XSELinux extension within Xorg to limit what the Xephyr server is allowed to do, including disabling use of SHM by it. That would have obvious performance implications, of course, but would have blocked this attack, while still allowing other non-sandboxed applications on the desktop to use SHM. -- Stephen Smalley National Security Agency -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
