#1679 closed defect (worksforme)
fedora 27 selinux policy error
Reported by: | Antoine Martin | Owned by: | Smo |
---|---|---|---|
Priority: | major | Milestone: | 2.2 |
Component: | platforms | Version: | trunk |
Keywords: | fedora selinux | Cc: |
Description (last modified by )
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:
Change History (7)
comment:1 Changed 3 years ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 Changed 3 years ago by
Description: | modified (diff) |
---|---|
Summary: | fedora 27 selinux policy error: xpra_port_t must be a port type → fedora 27 selinux policy error |
comment:3 Changed 3 years ago by
Owner: | changed from Antoine Martin to Smo |
---|---|
Status: | assigned → new |
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.
comment:4 Changed 3 years ago by
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.
comment:5 Changed 3 years ago by
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?)
comment:6 Changed 3 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:7 Changed 3 days ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1679
That's caused by this new rule
neverallow authlogin_typeattr_1 shadow_t (file (read)))
: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?