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

[Stephen Smalley]

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