Bug 1417908 - PAM-Yubico broken by SELinux [NEEDINFO]
Summary: PAM-Yubico broken by SELinux
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy (Show other bugs)
(Show other bugs)
Version: 7.3
Hardware: Unspecified Linux
low
low
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-31 12:07 UTC by Fabio Alessandro Locati
Modified: 2019-01-03 01:58 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
lvrabec: needinfo? (fale)


Attachments (Terms of Use)

Description Fabio Alessandro Locati 2017-01-31 12:07:56 UTC
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

Comment 2 Milos Malik 2017-01-31 12:25:43 UTC
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

#

Comment 4 Fabio Alessandro Locati 2017-01-31 14:03:12 UTC
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

Comment 5 Milos Malik 2017-02-01 09:32:12 UTC
(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.

Comment 6 Lukas Vrabec 2017-02-01 09:43:30 UTC
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.

Comment 7 Fabio Alessandro Locati 2017-02-01 10:22:32 UTC
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

Comment 10 Lukas Vrabec 2018-06-25 16:03:53 UTC
Hi, 

Are you able to reproduce the issue? 

Lukas.

Comment 12 Orion Poplawski 2018-11-15 22:59:53 UTC
I'm seeing the nssdb SELinux message as well with pam_yubico - though it doesn't appear to be affecting operation any for me.

Comment 13 Orion Poplawski 2018-11-15 23:02:01 UTC
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.


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