Hide Forgot
Description of problem: It seems like the 'authlogin_yubikey' sebool is not enough to make pam_yubico work properly. Version-Release number of selected component (if applicable): libyubikey-1.13-1.el7.x86_64 pam_yubico-2.23-1.el7.x86_64 selinux-policy-targeted-3.13.1-102.el7_3.13.noarch libselinux-utils-2.5-6.el7.x86_64 libselinux-python-2.5-6.el7.x86_64 selinux-policy-3.13.1-102.el7_3.13.noarch libselinux-2.5-6.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Install and configure pam_yubico as per https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html 2. Enable the sebool authlogin_yubikey 3. Ensure that SELinux is enforced Actual results: Authntication error Expected results: Everything should work Additional info: 1. If I put SELinux in permissive mode (and nothing else differs) it works 2. The following lines get logges in my /var/log/audit/audit.log: type=AVC msg=audit(1485863541.944:4263609): avc: denied { name_connect } for pid=15945 comm="sshd" dest=443 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:openvpn_port_t:s0 tclass=tcp_socket type=AVC msg=audit(1485863541.969:4263610): avc: denied { write } for pid=15945 comm="sshd" name="nssdb" dev="xvda1" ino=8523394 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir
Could you run following command on your machine? # seinfo --portcon=443 The seinfo tool comes from setools-console package. Based on the first AVC, the TCP port 443 is labeled openvpn_port_t on your machine. That's strange. The second AVC needs to be fixed in selinux-policy: # sesearch -s sshd_t -t cert_t -c dir -A -C -p write # sesearch -s sshd_t -t cert_t -c dir -D -C -p write #
Thanks a lot Milos for the quick reply :). > # seinfo --portcon=443 portcon tcp 443 system_u:object_r:openvpn_port_t:s0 portcon tcp 443 system_u:object_r:http_port_t:s0 portcon tcp 1-511 system_u:object_r:reserved_port_t:s0 portcon udp 1-511 system_u:object_r:reserved_port_t:s0 > Based on the first AVC, the TCP port 443 is labeled openvpn_port_t on your > machine. That's strange. Actually is not, I've openvpn tcp connection on port 443, and therefore it is tagged to make it work in that way. Would this be a problem? I'm not really sure why it should be trying to bind to port 443. > The second AVC needs to be fixed in selinux-policy: > > # sesearch -s sshd_t -t cert_t -c dir -A -C -p write > # sesearch -s sshd_t -t cert_t -c dir -D -C -p write Both commands return empty
(In reply to Fabio Alessandro Locati from comment #4) > Actually is not, I've openvpn tcp connection on port 443, and therefore it > is tagged to make it work in that way. Would this be a problem? I just didn't know why the TCP port 443 got such a label. > I'm not > really sure why it should be trying to bind to port 443. Me neither.
Fabio, I would say that you have some issues with labeling. From comment#4, it's looks like you have tcp port 443 labeled as openvpn_port_t which is wrong.
Thanks. I've removed the openvpn_port_t tag: portcon tcp 443 system_u:object_r:http_port_t:s0 portcon tcp 1-511 system_u:object_r:reserved_port_t:s0 portcon udp 1-511 system_u:object_r:reserved_port_t:s0 And now that problem went away. type=AVC msg=audit(1485943073.033:4411402): avc: denied { write } for pid=5393 comm="sshd" name="nssdb" dev="xvda1" ino=8523394 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir is still there. I've created the following policy, which fixes it: policy_module(local_pam_yubikey, 1.0) gen_require(` type sshd_t; type cert_t; ') allow sshd_t cert_t:dir write; Thought I'm not very sure _why_ pam_yubikey is trying to write in the nssdb. A caching thing for certificate pinning, maybe? Cheers, Fale
Hi, Are you able to reproduce the issue? Lukas.
I'm seeing the nssdb SELinux message as well with pam_yubico - though it doesn't appear to be affecting operation any for me.
Just as a side note - I ended up using a proxy configuration going through port 8080. I needed to allow sshd_t access to http_cache_port_t as well. I'm not sure how common that will be though.