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