[apparmor] [PATCH] aa-sandbox

[Jamie Strandboge]

On Sat, 2012-08-25 at 14:22 -0500, Jamie Strandboge wrote:
> 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.
> 

Ok, I pushed all this up to the new branch. When using '-x", it does:
- adds an explicit deny rule for ~/.Xauthority
- generates a dynamic Xauthority file for the session in 
  ~/.Xauthority-sandbox<DISPLAYNUMBER>
- adds an allow rule for ~/.Xauthority-sandbox<DISPLAYNUMBER>
- adds checks for xhost being properly setup
- updates the man page for the above and how to setup xhost and xauth
- adds the --with-xauthority option which can be used with --profile

With the above, the :0.0 display is no longer accessible. Eg:
$ ./aa-sandbox -t ~/sandbox-xterm -X /usr/bin/xterm
$ XAUTHORITY=~/.Xauthority DISPLAY=:0.0 xinput
No protocol spcified
Unable to connect to X server

I've also pushed a bunch of other fixes to the bzr branch. Let me know
if you'd prefer a patch.

Thanks!
-- 
Jamie Strandboge             | http://www.canonical.com