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

[Jamie Strandboge]

On Thu, 2018-07-12 at 20:24 +0300, Vincas Dargis wrote:
> 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/`.

I like the idea of tunables/env and tunables/env.d. With env.d, it
seems that system administrators could just drop something in there
instead of needing to use /etc/apparmor.d/local/tunables/env?

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180725/4fb0425d/attachment.sig>