Bug 1475107 - SELinux is preventing sshd from write access on the directory /etc/pki/nssdb
SELinux is preventing sshd from write access on the directory /etc/pki/nssdb
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lukas Vrabec
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-07-26 01:07 EDT by Paul DeStefano
Modified: 2018-01-08 07:23 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-01-08 07:23:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul DeStefano 2017-07-26 01:07:00 EDT
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):

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

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?
Comment 1 Paul DeStefano 2017-12-10 15:28:34 EST
Still getting this.
Comment 2 Jakub Jelen 2017-12-12 04:51:16 EST
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?
Comment 3 Paul DeStefano 2017-12-18 18:59:02 EST
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?
Comment 5 Jakub Jelen 2017-12-19 04:10:15 EST
Which yubikey libs? `pam_yubico`? What for? OTP? Does it work regardless this AVC?
Comment 6 Paul DeStefano 2017-12-20 00:17:34 EST
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.
Comment 7 Jakub Jelen 2017-12-21 05:48:47 EST
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.
Comment 8 Paul DeStefano 2017-12-21 05:55:00 EST
YubiKey OTP is network based and TLS secured.  I think that's why it tries.  Could that be it?
Comment 9 Jakub Jelen 2017-12-21 06:21:58 EST
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?
Comment 10 Paul DeStefano 2017-12-21 14:09:43 EST
I could try, I think there is a debug option for that module.  Okay, let me see what I can find...
Comment 11 Lukas Vrabec 2017-12-23 17:13:43 EST
Thank you for help!
Comment 12 Paul DeStefano 2018-01-08 01:03:09 EST
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.
Comment 13 Lukas Vrabec 2018-01-08 07:23:09 EST
Thanks Paul for research. 

I'll close this BZ, feel free to re-open it if you'll see this denial again. 


Note You need to log in before you can comment on or make changes to this bug.