[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