ValueError: Type xpra_port_t is invalid, must be a port type
Looks like they've changed something somewhere? PITA
This affects upgrades as well as installs.
selinux related tickets:
That's caused by this new rule neverallow authlogin_typeattr_1 shadow_t (file (read))):
sudo neverallow check failed at /var/lib/selinux/targeted/tmp/modules/100/authlogin/cil:261
(neverallow authlogin_typeattr_1 shadow_t (file (read)))
<root>
allow at /var/lib/selinux/targeted/tmp/modules/400/xpra_socketactivation/cil:126
(allow xpra_t shadow_t (file (read getattr open)))
Failed to generate binary
semodule: Failed!
The port error is a red herring: it occurs because the policy failed to load.
Problem is that we need to access shadow_t to verify passwords..
SELinux insides – Part2: Neverallow assertions: We need to be sure that we do not allow any unwanted/unsecure/dangerous actions. For example, we do not want to allow ordinary services to access /etc/shadow. We are not an ordinary service since we do authentication against the system passwords.
I followed all the rules and built policy with audit2allow and the semodule command blows up: sshd currently uses PAM to check passwords. One of the PAM modules that sshd uses is pam_unix. This module first tries to read /etc/shadow directly. If it gets permission denied it executes /sbin/unix_chkpwd. unix_chkpwd accepts the user name and password and indicates to pam_unix whether the password matches the username.
Maybe we can get by with "dontaudit" and let PAM fallback to chkpwd?
According to Why does it access /etc/shadow?: these two macros should be enough to make us use chkpwd via a subprocess (the process transition takes care of the selinux permissions) rather than the in-process access:
auth_use_pam(xpra_t) selinux_getattr_fs(xpra_t)
Unfortunately, that doesn't work at all here and PAM fails with a rather cryptic message:
audit[23562]: USER_AUTH pid=23562 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xpra_t:s0 \
msg='op=PAM:authentication grantors=? acct="antoine" exe="/usr/bin/python2.7" hostname=? addr=? terminal=? res=failed'
The hidden rule that causes this failure is shown with semodule -DB:
AVC avc: denied { read } for pid=27195 comm="xpra" name="shadow" dev="md123" ino=824634 \
scontext=system_u:system_r:xpra_t:s0 tcontext=system_u:object_r:shadow_t:s0 tclass=file permissive=0
So it is still trying to access /etc/shadow... For whatever reason.
And this is where it gets incredibly annoying. Even using the big hammer:
typeattribute xpra_t can_read_shadow_passwords;
To try to force allow access to the shadow file does not work because now we get a new unrelated error in a completely different place:
do_start_proxy()
AVC avc: denied { map } for pid=30530 comm="xpra" path="/dev/shm/uG1uyM" dev="tmpfs" ino=396632 \
scontext=system_u:system_r:xpra_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file permissive=0
Exception in thread start_proxy(SSL socket: ::ffff:127.0.0.1, 14500, 0, 0 <- ::ffff:127.0.0.1, 55396, 0, 0):
(..)
File "/usr/lib64/python2.7/multiprocessing/synchronize.py", line 75, in __init__
sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
OSError: [Errno 13] Permission denied
So r17340 allows both and seems to work. Should this be backported? meh.
@smo: just a FYI, feel free to just close.
r17340 broke all distros older than Fedora 27 as the new "map" selinux capability doesn't exist there... r adds a conditional patch to the spec file to take it out.
After testing in a Fedora 27 VM, looks like we also need r17390 + r17391 + r17402.
Whatever this new "map" thing is meant to do, it causes all sorts of problems.
(ldconfig also triggers audit warnings with "map" on /usr/bin/ldconfig - maybe there is a more generic way of execing subprocesses without needing this new permission?)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1679