fedora-selinux August 2010 archive
Main Archive Page > Month Archives  > fedora-selinux archives
fedora-selinux: Re: [sandbox] uid 0 <- Xorg <- Xephyr <

Re: [sandbox] uid 0 <- Xorg <- Xephyr <- $program <- $exploit

From: Stephen Smalley <sds_at_nospam>
Date: Thu Aug 19 2010 - 15:47:25 GMT
To: "Christoph A." <casmls@gmail.com>

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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux