Failure to Update Challenge in Systemwide C/R Configuration

[MureDanta]

I'm experimenting with challenge-response using a Yubikey 5 NFC on Fedora 30 with the pam_yubico-0:2.26-3.fc30.x86_64 package installed. When I set things up in the default mode, with the challenge file in ~/.yubico, everything seems to work OK, but when I modify the configuration to use a systemwide directory to hold the challenges I get a permissions error when the module attempts to write back the new challenge.

I configured the systemwide directory as /etc/yubico and set permissions as recommended:

 [root@mini yubico]# ls -ld /etc/yubico
drwx------. 2 root root 4096 Sep 11 17:31 /etc/yubico
[root@mini yubico]# ls -l /etc/yubico
total 4
-rw-------. 1 root root 244 Sep 11 16:46 garbage-9705696

What happens when I log in (with the Yubikey inserted, of course), is that I am able to log in, but in the debug log I see this:

debug: pam_yubico.c:838 (parse_cfg): called.
debug: pam_yubico.c:839 (parse_cfg): flags 0 argc 4
debug: pam_yubico.c:841 (parse_cfg): argv[0]=mode=challenge-response
debug: pam_yubico.c:841 (parse_cfg): argv[1]=chalresp_path=/etc/yubico
debug: pam_yubico.c:841 (parse_cfg): argv[2]=debug
debug: pam_yubico.c:841 (parse_cfg): argv[3]=debug_file=/var/log/yubico.log
debug: pam_yubico.c:842 (parse_cfg): id=0
debug: pam_yubico.c:843 (parse_cfg): key=(null)
debug: pam_yubico.c:844 (parse_cfg): debug=1
debug: pam_yubico.c:845 (parse_cfg): debug_file=4
debug: pam_yubico.c:846 (parse_cfg): alwaysok=0
debug: pam_yubico.c:847 (parse_cfg): verbose_otp=0
debug: pam_yubico.c:848 (parse_cfg): try_first_pass=0
debug: pam_yubico.c:849 (parse_cfg): use_first_pass=0
debug: pam_yubico.c:850 (parse_cfg): nullok=0
debug: pam_yubico.c:851 (parse_cfg): authfile=(null)
debug: pam_yubico.c:852 (parse_cfg): ldapserver=(null)
debug: pam_yubico.c:853 (parse_cfg): ldap_uri=(null)
debug: pam_yubico.c:854 (parse_cfg): ldap_bind_user=(null)
debug: pam_yubico.c:855 (parse_cfg): ldap_bind_password=(null)
debug: pam_yubico.c:856 (parse_cfg): ldap_filter=(null)
debug: pam_yubico.c:857 (parse_cfg): ldap_cacertfile=(null)
debug: pam_yubico.c:858 (parse_cfg): ldapdn=(null)
debug: pam_yubico.c:859 (parse_cfg): user_attr=(null)
debug: pam_yubico.c:860 (parse_cfg): yubi_attr=(null)
debug: pam_yubico.c:861 (parse_cfg): yubi_attr_prefix=(null)
debug: pam_yubico.c:862 (parse_cfg): url=(null)
debug: pam_yubico.c:863 (parse_cfg): urllist=(null)
debug: pam_yubico.c:864 (parse_cfg): capath=(null)
debug: pam_yubico.c:865 (parse_cfg): cainfo=(null)
debug: pam_yubico.c:866 (parse_cfg): proxy=(null)
debug: pam_yubico.c:867 (parse_cfg): token_id_length=12
debug: pam_yubico.c:868 (parse_cfg): mode=chresp
debug: pam_yubico.c:869 (parse_cfg): chalresp_path=/etc/yubico
debug: pam_yubico.c:899 (pam_sm_authenticate): pam_yubico version: 2.26
debug: pam_yubico.c:914 (pam_sm_authenticate): get user returned: garbage
debug: pam_yubico.c:490 (do_challenge_response): Checking for user challenge files
debug: pam_yubico.c:493 (do_challenge_response): Challenge files found
debug: util.c:219 (check_firmware_version): YubiKey Firmware version: 5.1.2

debug: pam_yubico.c:528 (do_challenge_response): Loading challenge from file /etc/yubico/garbage-9705696
debug: util.c:436 (load_chalresp_state): Challenge: 7b9c2bb213b9c8791f8bd21ad1c21855af28f838baa30a6f0d8c0b18176b01356b88d324f6ade3bdabb9c993e3d2bf97c9a67525dc4682c19cd59e833e5a87, hashed response: e39a1aa6f0119b315bfa5487caf6f80af3570c83, salt: 8f2b3c4810c57bc5bc70f6ee5a468878d0e81907e261f33d05bbf23746524b0c, iterations: 10000, slot: 2
debug: pam_yubico.c:604 (do_challenge_response): Got the expected response, generating new challenge (63 bytes).
debug: pam_yubico.c:659 (do_challenge_response): Cannot open file: /etc/yubico/garbage-9705696.Gji58G (Permission denied)
debug: pam_yubico.c:443 (display_error): conv returned: '(null)'
debug: pam_yubico.c:718 (do_challenge_response): Challenge response failed: Permission denied
debug: pam_yubico.c:1220 (pam_sm_authenticate): done. [Success]

so what happens is that, because the module is unable to write back the updated challenge, the next time I log in, it presents the same challenge, so the Yubikey computes a response based on that, which is then accepted, and what should be an OTP turns, essentially, into a static password. Do I need to set some SELinux labels to allow PAM access to /etc/yubico? Obviously I don't want to give users write access to this directory. Right now the directory/files have:

[root@mini etc]# ls -Zd yubico
unconfined_u:object_r:etc_t:s0 yubico
[root@mini etc]# ls -Z yubico
system_u:object_r:auth_home_t:s0 garbage-9705696
[root@mini etc]# 

[turkja]

Old topic, but is there some solution to this? I ran into similar issue with CentOS 8. It sounds like SELinux problem, but I didn't find anything from auditd logs.

If the challenge is in home directory, pam works flawlessly. I'm quite happy with that because I don't see any added value in having it in system directory, but people will try to do as documented.