9:24 a.m.
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?
kind regards,
Christoph
10:47 a.m.
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
7:03 p.m.
On 08/19/2010 05:47 PM, Stephen Smalley wrote:
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.
I see. I thought Xephyr and the sandboxed program run within the same
domain, but looking at the process table made it clear.
The logical next question would be: How confined is xserver_t actually? ;)
Curious as to whether they in fact wrote a successful exploit that
did
that, or just pointed out that it is theoretically possible.
I was also curious and asked on their blog, but didn't get a response.
thanks for your explanations,
Christoph
7:59 a.m.
On Tue, 2010-08-24 at 02:03 +0200, Christoph A. wrote:
On 08/19/2010 05:47 PM, Stephen Smalley wrote:
> 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.
I see. I thought Xephyr and the sandboxed program run within the same
domain, but looking at the process table made it clear.
The logical next question would be: How confined is xserver_t actually? ;)
xserver_t (the domain for the top-level Xorg) is highly privileged, and
is an unconfined domain under the default targeted policy.
$ sesearch -A -s xserver_t -c capability
Found 2 semantic av rules:
allow xserver_t xserver_t : capability { chown dac_override
dac_read_search fowner fsetid kill setgid setuid setpcap linux_immutable
net_bind_service net_broadcast net_admin net_raw ipc_lock ipc_owner
sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin sys_boot
sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap } ;
allow xserver_t xserver_t : capability net_bind_service ;
sandbox_xserver_t (the domain for the Xephyr instance for the sandboxed
application) is far more limited.
$ sesearch -A -s sandbox_xserver_t -c capability
Found 2 semantic av rules:
allow sandbox_xserver_t sandbox_xserver_t : capability
{ net_bind_service audit_write } ;
allow sandbox_xserver_t sandbox_xserver_t : capability
net_bind_service ;
--
Stephen Smalley
National Security Agency
5009
days inactive
5014
days old
selinux@lists.fedoraproject.org
3 comments
2 participants
participants (2)
-
Christoph A. -
Stephen Smalley