[apparmor] [PATCH] aa-sandbox

[Jamie Strandboge]

On Fri, 2012-08-24 at 13:05 -0500, Jamie Strandboge wrote:
> * audit our usage of various X servers

So, this is fun. While xeyes and gedit and everything are in their own X
server and can't see applications outside of the X server by default,
here is something fun to try:

$ aa-sandbox ... -X /usr/bin/xterm # need a special profile for xterm

From inside the xterm in xpra:
$ xinput list # list keyboards on our display
...
Xvfb keyboard

Ok, cool, that worked as expected.

$ DISPLAY=:0.0 xinput list
...
AT Translated Set 2 keyboard     id=12 [slave  keyboard (3)]

Oh, that's neat-- and yes, this works:
$ DISPLAY=:0.0 xinput test 12
<scancodes for every keypress on :0.0>


On Ubuntu, this works because we use xhost and have an Xsession.d script
(actually, two of them) that does:
[ -x /usr/bin/xhost ] && [ -x /usr/bin/id ] &&
    xhost +si:localuser:`id -un` > /dev/null

Ie, for me:
$ xhost
access control enabled, only authorized clients can connect
SI:localuser:myname

This says that any local process running under my usename ('myname') can
connect to this X server (ie, the one on :0.0). This is precisely what
we do not want since the application in xpra runs as our user. So one
way to solve this is by going back to xauth and utilizing existing
Xsecurity features. Eg, if I create /etc/X11/Xsession.d/90xsecurity:
# Create an Xauthority file if it doesn't exist
[ ! -f "$HOME/.Xauthority" ] && [ -x /usr/bin/xauth ] &&
    xauth generate :0 . trusted > /dev/null

# Remove the xhost entry so we can just use Xauthority
[ -f "$HOME/.Xauthority" ] && [ -x /usr/bin/xhost ] && [ -x /usr/bin/id ] &&
    xhost -si:localuser:`id -un` > /dev/null

This creates a trusted entry in the ~/.Xauthority file, so anything able
to read ~/.Xauthority can run on :0.0. Unconfined applications and
confined applications with the 'X' abstraction are able to read this
file. If we adjust our sandbox-x template to include:
audit deny @{HOME}/.Xauthority mrwlk,

Then we can block connections to :0.0. Eg:
$ aa-sandbox ... -X /usr/bin/xterm
$ export DISPLAY=:0.0                  # in the xterm
$ XAUTHORITY=~/.Xauthority xinput list # generates an apparmor denial
No protocol specified
Unable to connect to X server

What aa-sandbox needs to do then is create an Xauthority file for each
sandboxed application and then add rules so that a process cannot hard
link to other Xauthority files but can access its own Xauthority file. I
have a preliminary patch to do just that and will submit soonish.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20120825/92648e7e/attachment.pgp>