[apparmor] [RFC] How should we deal with /tmp/xauth* ?

[Vincas Dargis]

On 7/9/18 3:43 PM, Simon McVittie wrote:
> On Sun, 08 Jul 2018 at 14:55:35 +0300, Vincas Dargis wrote:
>> Though sysdig shows some sort of zoo of variations, some applications uses
>> `/tmp/xauth`, others $HOME/.Xauthority, and also there's
>> `/home/vincas/.kde/tmp-vinco/xauth-1000-_0MT2492.new`
> 
> This is also application-specific. Anything that sets up an X11
> session (a display manager like gdm or lightdm, distro scripts like
> /etc/X11/Xsession.d, a nested X11 display like Xephyr or xvfb, a remoting
> protocol implementation like xrdp or xpra, etc., and perhaps also desktop
> sessions like gnome-session or startkde) can set up xauth authority
> files according to its own designer's preference.
> 
> How they're set up is also dependent on the scope of the X server.
> Historically, display managers normally started an X server as root for
> the "greeter" (login prompt) and then recycled the same X server for the
> user session that results from a login; but now that X does not always
> need to run as root, some display managers (definitely including gdm,
> possibly others) have started to use separate X servers for the greeter
> and the user session.  This has implications for where the xauth authority
> file is located (it must be visible to all uids that will share the X
> server) and also for its file ownership (whether you can restrict the
> AppArmor rule with "owner" or not).

Thanks for great insight!

Looks like we need kinda more flexible approach. I doubt AppArmor upstream profiles/abstractions 
should handle variety of scenarios explicitly for all these packages.

I'd say we need to use tunables, and I actually wanted to start (ugh, yet another? :) ) discussion 
suggesting to ship new `tunables/env` (name might differ of course) where we would have TMPDIR, 
XAUTHORITY and any other relevant customization points defined that depends on applications 
environment variables.

Any "third-party" application, like Xephyr or gdm, that launches possibly confined applications and 
changes environment so that `XAUTHORITY` or any other path is effectively made different from 
"common defaults", could ship `/etc/apparmor.d/tunables/env.d/foo` file to register these needed 
changes by adding `@{XAUTHORITY} += /tmp/xauth-[0-9]*-[0-9]` or similar declarations.

In addition, `/etc/apparmor.d/local/tunables/env` file (included with `#include if exists` within 
`tunables/env`) could be used by system administrators to change TMPDIR, as there is need for that 
as already seen in Debian bug report [0].

Once everything is set in place,`abstractions/X` could use `@{XAUTHORITY}` variable, and any 
application profile should use `@{TMPDIR}` instead of hard-coding `/tmp/`.


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900210