socket activation for system proxy server

[Antoine Martin]

May help with #1105.

Looks simple enough.

• get the list of sockets using ​sd_listen_fds (will require small cython glue code)
• add them to our list of sockets we listen on

We can probably do this no matter what, if the server is not socket-activated this will do nothing.

[Antoine Martin]

support socket activation

[Antoine Martin]

The patch above almost works, but I had to disable selinux to avoid this avc denial:

systemd[1]: xpra.socket: Failed to listen on sockets: Permission denied
systemd[1]: Failed to listen on Xpra Socket.
systemd[1]: xpra.socket: Unit entered failed state.

audit[1]: AVC avc:  denied  { create } for  pid=1 comm="systemd" \
    scontext=system_u:system_r:init_t:s0 \
    tcontext=system_u:system_r:unconfined_service_t:s0 \
    tclass=tcp_socket permissive=0

Then you can test with:

#install latest xpra
systemctl daemon-reload
systemctl stop xpra.service
systemctl restart xpra.socket
systemctl status xpra.socket
xpra info socket:/var/run/xpra/system 
#or
#xpra info tcp:127.0.0.1

And the "system" instance is started.

[Antoine Martin]

Merged in r15895 with one caveat: the TCP socket is not socket activated yet because of the selinux AVC - which looks like this ticket: ​SELinux does not allow systemd to create a TCP/UDP socket.

The proxy server now uses the "peercred" auth module (see #1524).
The unix domain socket location has been changed to /var/run/xpra/system.
This new socket location is not seen by default by subcommands like "xpra list". (r15896 prevents us from creating another one as /var/run/xpra/${hostname}-14500 - which isn't useful anyway)

Keeping this ticket open until the AVC problem is resolved, so we can add the TCP socket to the systemd socket activation.

[Antoine Martin]

Dammit, even the unix domain socket is broken with selinux enabled. Raising.

Maybe we need a policy? Hopefully just a simple label for the service file? (not a full policy #1283)

[Antoine Martin]

Debian packaging build fix in r15936

[Antoine Martin]

r15995 uses the lax selinux policy so we no longer block #1105, but this will need to be done properly before the release.
We want to change from:

allow init_t unconfined_service_t:unix_stream_socket { create setopt bind listen };
allow init_t unconfined_service_t:tcp_socket { create setopt bind listen };

To something much more strict, labelling the unix domain socket and adding another type for the tcp socket. (ie: xpra_socket_t?)

[Antoine Martin]

basic policy for the system proxy server only

[Antoine Martin]

SELinux policy added in r16014, RPM packaging in r16015.

It is incomplete, I don't quite understand why some files are labelled correctly:

$ ls -lZ /lib/systemd/system/xpra* /usr/bin/xpra* /var/run/xpra.pid
-rw-r--r--. 1 root root system_u:object_r:xpra_unit_file_t:s0 760 Jun  4 19:32 /lib/systemd/system/xpra.service
-rw-r--r--. 1 root root system_u:object_r:xpra_unit_file_t:s0 304 Jun  4 19:32 /lib/systemd/system/xpra.socket
-rwxr-xr-x. 1 root root system_u:object_r:xpra_exec_t:s0      384 Jun  4 19:31 /usr/bin/xpra
-rwxr-xr-x. 1 root root system_u:object_r:xpra_exec_t:s0      208 Jun  4 19:31 /usr/bin/xpra_browser
-rwxr-xr-x. 1 root root system_u:object_r:xpra_exec_t:s0      226 Jun  4 19:31 /usr/bin/xpra_launcher
-rw-------. 1 root root system_u:object_r:xpra_pid_t:s0         5 Jun  4 21:31 /var/run/xpra.pid

But others aren't:

$ ls -lZ /var/run/xpra/system
srw-rw-rw-. 1 root xpra system_u:object_r:var_run_t:s0 0 Jun  4 21:31 /var/run/xpra/system

So the policy ends up being less strict than it could be.
But it is still better than no policy and it does not lower the restrictions on any other domains, unlike the naive ​audit2allow solution. We can follow up in #1283.

---

@afarr: mostly a FYI, see comment:1 for testing. Both sockets should be listening as soon as the package is installed: /run/xpra/system (unix domain socket) and 0.0.0.0:14500.
Trying to connect to either of them will cause the xpra.service to start.
This can be seen using journalctl -f or systemctl status xpra.service.

[Antoine Martin]

r16058 fixes the following warnings on centos7:

[/usr/lib/systemd/system/xpra.service:16] Failed to parse protect system value, ignoring: strict
[/usr/lib/systemd/system/xpra.service:17] Unknown lvalue 'ReadWritePaths' in section 'Service'
[/usr/lib/systemd/system/xpra.service:19] Unknown lvalue 'ProtectKernelTunables' in section 'Service'
[/usr/lib/systemd/system/xpra.service:20] Unknown lvalue 'ProtectControlGroups' in section 'Service'

(older systemd versions just don't have those options)

[Antoine Martin]

New problem seen on centos7: ctypes tries to write to /tmp and fails.
See:

• ​libffi shipped in python runs afoul of SELinux when embedded in apache
• ​Occasional ctypes error importing numpy from mod_wsgi django app
• ​libffi using applications cannot run in Fedora under SELinux* ​cffi cdef: changing CFFI_TMPDIR doesn't seem to make any difference

[Antoine Martin]

Updated policy as of r16066 allows us to call the pam authentication plugin used by the system proxy server.
Was not easy to figure out as some avc denials were hidden, uncovered them with semodule -DB.
Tested repeatedly with:

semanage port -d -p tcp 14500
semodule -r xpra_socketactivation
make clean && make
semodule -i xpra_socketactivation.pp
semanage port -a -t xpra_port_t -p tcp 14500
systemctl stop xpra.service
systemctl restart xpra.socket
systemctl status xpra.socket

I think there may still be a problem with package upgrades vs installs, so taking the ticket back for further package installation testing.

[Antoine Martin]

Lots of tricksy RPM packaging fixes:

• r16071: install and upgrade were mixed up! (doh)
• r16072: we wrongly restarted the service on upgrade
• r16073: selinux port label must be removed before we can unload the selinux modules, and only then (don't remove on upgrade!)
• r16078: always define the selinux port (could be upgrading from older version), just ignore errors if already defined
• r16075: don't remove firewall rules when doing an upgrade (should be backported?)
• r16076 + r16077: avoid RPM installation warnings if the firewall port is already defined (ie: during upgrades)

Reference link: ​Fedora Packaging Guidelines for RPM Scriptlets

---

With these changes, the RPM transaction should not be emitting any warnings and the following pieces should always be in a consistent state (after an install or upgrade):

• port added to the firewall
• selinux policy loaded, selinux port registered
• socket unit started
• the proxy server can be queried, ie: xpra info socket:/var/run/xpra/system or xpra info tcp/username:password@HOST/

Conversely, removing the package should undo everything.

Tested on Fedora 26 and centos7.

@smo: mostly a FYI, feel free to close.

[Antoine Martin]

crickets - works for me

[Antoine Martin]

Re-tested as I investigated a proxy server bug on Ubuntu 16.04 and found that all Debian / Ubuntu distros were enabling and starting the service instead of relying on socket activation. r16813 fixes that. (will backport)
Unfortunately, that doesn't make any difference to Ubuntu 16.04, which still starts the service and somehow also gets the sockets messed up: the service is unreachable as both the 0.0.0.0:14500 and /run/xpra/system sockets timeout.
So r16814 + r16815 uses a custom service file without socket activation, just for Ubuntu 16.04. PITA.

For SSL issues, see #1636.

[Antoine Martin]

Fedora 27 broke the selinux policy: #1679

[Antoine Martin]

Debian packaging of the ssl cert is a mess: #1721

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/1521