fedora 27 selinux policy error

[Antoine Martin]

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:

• #1283
• #815
• ticket:1521#comment:10

[Antoine Martin]

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?

[Antoine Martin]

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.

[Antoine Martin]

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.

[Antoine Martin]

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

[migration script]

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