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

Jamie Strandboge jamie at canonical.com
Fri Jul 6 16:45:36 UTC 2018


On Sun, 2018-07-01 at 15:50 +0300, Vincas Dargis wrote:
> 
> No after these things being said, I am not really sure how to handle
> this case because this file 
> access does not seem to be critical or universal. Hence, few
> questions:
> 
> Q1: Does anyone knows security implications, use case and importance
> for this file?

Systems that use xauth as a mechanism are going to need to access the
Xauthority file. See 'man Xsecurity'.

> Q2: Why I cannot reproduce it on other distros?
> 
I suspect it is because other distros don't use xauth. For example,
Ubuntu uses 'server interpreted':

$ xhost
access control enabled, only authorized clients can connect
SI:localuser:jamie

This is setup in /etc/X11/Xsession.d/60x11-common_localhost. I'm
surprised that the Debian packaging would differ here...

> Q3: Do you believe this file rule `owner /tmp/xauth-[0-9]*-[0-9]* r,`
> should be placed:
>    a) Into `abstrations/X`.
>    b) Into it's own abstraction `abstractions/libxau` (or similar).
>    c) Put this rule into individual application profiles (as this
> does not seem critical or universal).
>    d) ?
> 

Based on my reading of libxau-1.0.8/AuGetBest.c, auGetBestAuthByAddr()
looks at XauFileName() which going to default to ~/.Xauthority if
XAUTHORITY isn't set. On the system you are looking at, it sounds like
XAUTHORITY is set to "/tmp/xauth-1000-_0". If it can be determined what
is setting XAUTHORITY in this manner and this is done distro-wide, then
'a' is the correct approach. In lieu of that, 'c'.

-- 
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/20180706/a469207d/attachment.sig>


More information about the AppArmor mailing list