site  contact  subhomenews

Xorg .Xauthority is extra protection

July 02, 2018 — BarryK

I don't know of any pups that have bothered with this, however, ~/.Xauthority is an extra level of security, that I have now implemented in EasyOS.

I am playing with running X apps in containers with the Xephyr nested X server. In /usr/bin/xwin, I now launch Xorg with "-nolisten tcp -nolisten local", which prevents any app to connect to the Xorg server via a TCP port or what is called an "abstract socket".

That leaves /root/.X11-unix/X0 a Unix Domain Socket. This is how apps will communicate with Xorg.

Inside a container, it is still possible to connect with Xorg :0, even though apps inside the container cannot "see" /root/.X--unix/X0 in the host. This can be done with 'socat'. Do this in the host:

# socat -ly -d -d TCP-LISTEN:6000,fork,bind=localhost UNIX-CONNECT:/tmp/.X11-unix/X0 &

Then in the container:

# export DISPLAY=localhost:0

However, Xorg itself is considered to have many security weaknesses, and one step-up to improve security is to use Xephyr, which is a nested kdrive X server. I am running this on DISPLAY :1, launched in the host,

Putting that aside, while reading up on X xecurity, it seemed to me that it will be a good thing to implement /root/.Xauthority. A "cookie" can be placed in this file, and any other computer that wants to connect to our local Xorg must have a matching cookie in its own ~/.Xauthority file.

So, /etc/rc.d/rc.sysinit now has this, just after the hostname is autogenerated:

 xPW="$(< /dev/urandom tr -dc 'a-f0-9' | head -c32)"
echo -n '' > /root/.Xauthority
xauth -f /root/.Xauthority add ${PUPHOSTNAME}/unix:0 . ${xPW}

The hostname may also be changed in QuickSetup, /usr/sbin/quicksetup, which calls /usr/sbin/hostname-set. So, the same code is now in hostname-set, just after writing to /etc/hosts.

I think that I have got it right, not verified yet! If I haven't, if the cookie has the wrong hostname, then the desktop will become non-functional.

There is something called "FamilyWild", which basically enters a wildcard in place of the hostname. That means the cookie will work for all local displays, regardless of what the hostname is. Unfortunately, I want to distinguish between :0 and :1, whereas the docs state that FamilyWild applies to "all displays".

Here is some further info:


A special connection family (FamilyWild, value 65535) causes an entry to match every display, allowing the entry to be used for all connections.

For the record, I found this on the Internet, a way to convert a cookie to FamilyWild:

# touch test1
# xauth nlist :0 | sed -e '/^..../ffff/' | xauth -f test1 nmerge -
# xauth -f test1 list

Tags: easy