4

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: enter image description here

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:

  1. 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?
  2. Should I just report the bug and create the local policy module, or something else?
  3. Should I undo the transaction that led to all this and update the packages in smaller groups? Would it even undo the problem?
  4. 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/fstab can 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: enter image description here

  • Its odd that the sss program doesn't write on its own cache. What is ls -Z /var/lib/sss/db, what selinux context is sss run as? What is the error from the audit log? – danblack Dec 4 '18 at 2:31
  • @user1133275 I let the fedora install do what the fedora install wanted. I've been using Linux for almost 2 years now (not on a daily basis), so I'm 100% noob, and don't know enough to tell Fedora what to do. :( – Ungeheuer Dec 4 '18 at 3:00
  • @danblack I don't know how to find the context for a non-running process. I can see how to do it via ps, but sss_cache is non-running, so ps doesn't work. I did find something perhaps useful by running ls -Z on the location where sss_cache binary lives. – Ungeheuer Dec 4 '18 at 3:43
  • Other than the selinux alerts, is there a problem with the system? Probably your best option is to either file a bug report as advised or you can debug a but. Take a look at ausearch , audit2why , and audit2allow. Read wiki.centos.org/HowTos/SELinux . – Panther Dec 4 '18 at 6:58
  • @Panther Immediately after I saw the report the machine felt slower. I decided to do a reboot (ended up doing 2), and the slowdown was obvious when loading the Fedora logo, the login GUI, and the desktop environment. – Ungeheuer Dec 4 '18 at 13:17
5

Looks like a bug in Fedora's SELinux policy.

Before the fix is released, you can use audit2allow generated policy or the policy in the bug report to allow access.

  • 1
    I guess I missed that result in the original googling. Thanks for the link bruv. I've never encountered a bug before. Would it be appropriate to link this question in the bugzilla report? – Ungeheuer Dec 4 '18 at 13:15
  • 1
    @Ungeheuer it doesn't hurt, especially since it seems like maybe the problem has crept back in after an initial fix. – mattdm Dec 5 '18 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.