xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 4 weeks ago

#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)

socket-activation.patch (5.6 KB) - added by Antoine Martin 3 months ago.
support socket activation
selinux-system-proxy-policy.patch (3.0 KB) - added by Antoine Martin 3 months ago.
basic policy for the system proxy server only

Download all attachments as: .zip

Change History (13)

Changed 3 months ago by Antoine Martin

Attachment: socket-activation.patch added

support socket activation

comment:1 Changed 3 months ago by Antoine Martin

Status: newassigned

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 months ago by 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.

Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:3 Changed 3 months ago by Antoine Martin

Priority: majorblocker

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:4 Changed 3 months ago by Antoine Martin

Debian packaging build fix in r15936

comment:5 Changed 3 months ago by Antoine Martin

Priority: blockercritical

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?)

Last edited 3 months ago by Antoine Martin (previous) (diff)

Changed 3 months ago by Antoine Martin

basic policy for the system proxy server only

comment:6 Changed 2 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

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.

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 2 months ago by 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)

comment:8 Changed 2 months ago by Antoine Martin

comment:9 Changed 2 months ago by 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.

comment:10 Changed 2 months ago by Antoine Martin

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 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.

comment:11 Changed 4 weeks ago by Antoine Martin

Resolution: fixed
Status: newclosed

crickets - works for me

Note: See TracTickets for help on using tickets.