#1521 closed enhancement (fixed)
socket activation for system proxy server
Reported by: | Antoine Martin | Owned by: | Smo |
---|---|---|---|
Priority: | critical | Milestone: | 2.1 |
Component: | server | Version: | trunk |
Keywords: | Cc: |
Description
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.
Attachments (2)
Change History (16)
Changed 3 years ago by
Attachment: | socket-activation.patch added |
---|
comment:1 Changed 3 years ago by
Status: | new → assigned |
---|
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.
comment:2 Changed 3 years ago by
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.
comment:3 Changed 3 years ago by
Priority: | major → blocker |
---|
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)
comment:5 Changed 3 years ago by
Priority: | blocker → critical |
---|
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
?)
Changed 3 years ago by
Attachment: | selinux-system-proxy-policy.patch added |
---|
basic policy for the system proxy server only
comment:6 Changed 3 years ago by
Owner: | changed from Antoine Martin to alas |
---|---|
Status: | assigned → new |
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
.
comment:7 Changed 3 years ago by
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)
comment:8 Changed 3 years ago by
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
comment:9 Changed 3 years ago by
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.
comment:10 Changed 3 years ago by
Owner: | changed from alas to Smo |
---|
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
orxpra 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.
comment:12 Changed 2 years ago by
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.
support socket activation