Description of problem: After upgrade to F26 I still get this AVC. type=AVC msg=audit(1501044994.332:348): avc: denied { write } for pid=16254 comm="sshd" name="nssdb" dev="dm-2" ino=393836 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0 Version-Release number of selected component (if applicable): openssh-server-7.5p1-3.fc26.x86_64 selinux-policy-3.13.1-260.1.fc26.noarch How reproducible: immediately on boot after F26 upgrade, but I think this has been happening for a long time, right? Steps to Reproduce: 1. install openssh-server 2. make some remote connections 3. Actual results: AVC alert Expected results: no AVC alert Additional info: Happened a very long time ago and I don't think it stopped. I just deleted my 'ignores' so I was surprised to see it was still happening. I also search for an existing bug expecting to find it. I cannot be the only person seeing this, right?
Still getting this.
I do not see this with my machine. Only a variation of this from Fedora 26: type=AVC msg=audit(1502967804.961:1757): avc: denied { search } for pid=21528 comm="sshd" name="pki" dev="dm-1" ino=655367 scontext=system_u:system_r:tcpd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0 The OpenSSH code itself certainly does not need to touch this , but it might be some PAM module or even SSSD? Can you share some timestamped debug log from SSHD if you can reproduce it, so we could pinpoint where does it come from?
Ah, right; I'm remembering now. I have yubikey libs installed and configured in PAM for SSH. I think that is why this happens. I remember now, I reported it before. Sorry, I guess it doesn't matter. Do you think it matters? If it where to get fixed, would that be yubikey or selinux package?
Which yubikey libs? `pam_yubico`? What for? OTP? Does it work regardless this AVC?
Yes, pam_yubico. I have all the yubikey pkgs installed for management, too, btw. OTP, yes, exactly. Yes, even with AVC, there isn't any problem authenticating.
I believe it is a local OTP so for this I don't see any reason why it would need to consult NSS PKI database. I believe the NSS DB initialization is in the PAM module for other means of authentication, for example local and it is merely a bug in the pam module. From SELinux point of view, I don't think it makes sense to allow this, even conditionally.
YubiKey OTP is network based and TLS secured. I think that's why it tries. Could that be it?
If it is network based, then it should certainly check against the NSS DB. But then comes a question why does it work without it. Are you able to get some debug logs from the pam module?
I could try, I think there is a debug option for that module. Okay, let me see what I can find...
Jakub, Thank you for help!
Hmm, I tried to debug pam_yubico, but it wouldn't produce a debug file, as directed. I'm confused. To make matters worse, SEAlert is misbehaving; it doesn't show any AVCs, even though it pops up in the system tray. Nevertheless, I checked the journal, manually, and now I see that the last time this AVC was logged was 6 Dec 2017, before comment 1, but after I upgraded to fedora27. So, it seems like it's gone. I think SEAlert has been confusing me by not really deleting reports I told it to delete.
Thanks Paul for research. I'll close this BZ, feel free to re-open it if you'll see this denial again. Lukas.