System:
- HP Pavilion Power Laptop 15-cb0xx
- Intel i7-7700HQ w/ integrated graphics enabled (can't be turned off in bios)
- Fedora 28
- NVIDIA GTX 1050 (mobile)
I used the dnfdragora GUI to update about 119 packages (I forgot to update for a while :/). At some point I got a notification from SELinux:
SELinux is preventing sss_cache from write access on the directory /var/lib/sss/db/
I dug through /var/log/messages and /var/log/audit/audit.log and found the same stuff that SELinux told me.
After all this went down, I noticed things were going kind of slowly, so I rebooted. The reboot was slower, particularly obvious when the Fedora logo was loading, when the login GUI was loading, and when the desktop was loading. An additional reboot did not fix anything.
From looking at the manpage for sss_cache I get the gist of what it does, and that it works with the System Security Services Daemon (SSSD).
This is what the SELinux dialog box is telling me:
I understand that this will notify the maintainers of a potential bug, and the policy changes will prevent SELinux from alerting on sss_cache in the future. I do not know anything about SELinux other than it provides added/configurable security additions to a Linux system. However, I still do not understand why this happened, or if there are other, potentially better, solutions. Nor is it clear to me if this will clear up the slowdown issues I noticed.
Can anyone tell me:
- Why this might have happened? I can guess that SELinux considers anything associated with SSSD as very important to protect, but why is it not aware of a utility meant to work with SSSD?
- Should I just report the bug and create the local policy module, or something else?
- Should I undo the transaction that led to all this and update the packages in smaller groups? Would it even undo the problem?
- Could this have caused the slowdown issues I noted above? I know from working with VMs (specifically expanding storage space in VirtualBox) that leaving an old entry
/etc/fstabcan slow down boot because the system is looking for something that doesn't exist. Is something similar going on here?
I am loath to just do what the words on the screen say without additional information. I don't want to put a band-aid on a bomb crater without realizing it.
(Additional Information as Requested):
I should have stated: /var/lib/sss/db/ is a directory.
ls -Z /var/lib/sss/ output for db/: system_u:object_r:sssd_var_lib_t:s0
Excerpt from audit.log (includes a potentially unrelated line sandwiched between two relevant ones):
type=AVC msg=audit(1543865969.237:241): avc: denied { write } for pid=18065 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
type=GRP_MGMT msg=audit(1543865969.239:242): pid=18062 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:groupadd_t:s0 msg='op=modify-group acct="rpcuser" exe="/usr/sbin/groupmod" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1543865969.264:243): avc: denied { write } for pid=18067 comm="sss_cache" name="db" dev="sdb2" ino=787765 scontext=system_u:system_r:groupadd_t:s0 tcontext=system_u:object_r:sssd_var_lib_t:s0 tclass=dir permissive=0
Output of ls -Z /usr/sbin/sss_cache (location found via which sss_cache):
system_u:object_r:bin_t:s0
Turns out the "details" window had a lot of info:
sssprogram doesn't write on its own cache. What isls -Z /var/lib/sss/db, what selinux context issssrun as? What is the error from the audit log? – danblack Dec 4 '18 at 2:31ps, butsss_cacheis non-running, sopsdoesn't work. I did find something perhaps useful by runningls -Zon the location wheresss_cachebinary lives. – Ungeheuer Dec 4 '18 at 3:43