Description of problem: SELinux is preventing google-authenticator to work on fresh installed CentOS 8.1 Version-Release number of selected component (if applicable): google-authenticator-1.07-1.el8.x86_64 selinux-policy-3.14.3-20.el8.noarch openssh-server-8.0p1-4.el8_1.x86_64 kernel-4.18.0-147.8.1.el8_1.x86_64 How reproducible: Steps to Reproduce: 1. Setup CentOS 8.1 2. install google-authenticator from epel along with qrencode 3. setup google-authenticator - create a time-based token - add pam_google_authenticator to sshd pam-file - set ChallengeResponseAuthentication to yes in sshd_config 4. try to login with OTP Token Actual results: No login possible Expected results: Login possible Additional info: # journalctl -u sshd May 26 13:26:04 localhost.localdomain sshd(pam_google_authenticator)[2168]: Accepted google_authenticator for testuser May 26 13:26:04 localhost.localdomain sshd(pam_google_authenticator)[2168]: Failed to create tempfile "/home/testuser/.google_authenticator~6wwsWT": Permission denied May 26 13:26:04 localhost.localdomain sshd(pam_google_authenticator)[2168]: Failed to update secret file "/home/testuser/.google_authenticator": Permission denied May 26 13:26:06 localhost.localdomain sshd[2166]: error: PAM: Authentication failure for testuser from ::1 May 26 13:26:08 localhost.localdomain sshd[2166]: Connection closed by authenticating user testuser ::1 port 41906 [preauth] # sealert -l '*' SELinux is preventing /usr/sbin/sshd from create access on the file .google_authenticator~6wwsWT. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that sshd should be allowed create access on the .google_authenticator~6wwsWT file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'sshd' --raw | audit2allow -M my-sshd # semodule -X 300 -i my-sshd.pp Additional Information: Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023 Target Context system_u:object_r:user_home_dir_t:s0 Target Objects .google_authenticator~6wwsWT [ file ] Source sshd Source Path /usr/sbin/sshd Port <Unknown> Host localhost.localdomain Source RPM Packages openssh-server-8.0p1-4.el8_1.x86_64 Target RPM Packages Policy RPM selinux-policy-3.14.3-20.el8.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 4.18.0-147.8.1.el8_1.x86_64 #1 SMP Thu Apr 9 13:49:54 UTC 2020 x86_64 x86_64 Alert Count 1 First Seen 2020-05-26 13:26:04 CEST Last Seen 2020-05-26 13:26:04 CEST Local ID 7f01cea6-b0c0-4786-bfeb-0f209c18aadb Raw Audit Messages type=AVC msg=audit(1590492364.383:140): avc: denied { create } for pid=2168 comm="sshd" name=".google_authenticator~6wwsWT" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=file permissive=0 type=SYSCALL msg=audit(1590492364.383:140): arch=x86_64 syscall=openat success=no exit=EACCES a0=ffffff9c a1=56009cbb3e70 a2=c2 a3=180 items=0 ppid=2166 pid=2168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=1000 egid=1000 sgid=0 fsgid=1000 tty=(none) ses=4294967295 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) Hash: sshd,sshd_t,user_home_dir_t,file,create
I think we should ensure ~/.google-authenticator.* gets the right label where sshd_t can read/write to. Question is which one.
Well the various online instructions suggest putting it into ~/.ssh/ and letting restorecon set that up like anything else in ~/.ssh. That's working fine on my F32 systems. $ ls -lZ .ssh/.google_authenticator -r--------. 1 atrus atrus system_u:object_r:ssh_home_t:s0 194 07-15 20:38 .ssh/.google_authenticator Now there's nothing else ssh-specific about google-authenticator, (except that it's almost only used for ssh-based logins). Is there any other precedent for files in a home directory that need to be read before a login is considered successful? (See also: accessing files like these in a systemd-homed world -- a tangent, but the same sets of problems).
Not only SSH is affected by this bug. Cockpit for example is also broken.
I came across this problem on Centos 8 as well (although not trying to edit for pam.d for ssh, but another pam.d entry). I found this helpful solution: https://github.com/google/google-authenticator-libpam/issues/101 Specifically, the entry from DPStokesNZ on Aug 27, 2019. DPStokesNZ suggested making a new directory, .ga and adding a fcontext for that directory to auth_home_t. It turns out there is already a context for .google_authenticator for auth_home_t, but apparently it isn't 'wide' enough as it is an exact match on .google_authenticator or .google_authenticator~. It seems from looking at the selinux errors, google-authenticator now needs access to a random string file, like '.google_authenticator~RXfiek'. My fcontext foo wasn't sufficiently advanced, so my attempts to expand the net didn't work, but YMMV. However, following the directions from the above linked post, I was able to get this working with a minimum of changes. Recommend that Fedora / EPEL take a look at widening the fcontext for .google_authenticator to include the wider file name matches.
This is what should be added imho: semanage fcontext --add -s unconfined_u -r s0 -t auth_home_t '/home/[^/]+/\.google_authenticator~.*' I tried to come up with a patch again selinux-policy: https://github.com/fedora-selinux/selinux-policy/pull/469 and thus will switch the component to there, as everything can be solved there, since the google-authenticator RPM is not doing anything with selinux.
If this has to be fixed in selinux-policy, then selinux-policy needs that fix for Fedora + RHEL.
Hi, This problem cannot be fixed in selinux-policy. While we can assign default file context for a regexp, transitions do not work for regexps. As the most straightforward solution, I suggest to use ~/.config/google-authenticator as the configuration directory. We can subsequently back the updated settings in selinux-policy. If using a file in user's home is necessary, there are other solutions (setfscreatecon(), run restorecon afterwards) which can be handled and maintained in the application code.
thanks for the hints. It should be doable to move the location, we might need to apply a patch, but that should be fine. But still, we would need ~/.config/google-authenticator to be correctly labled first, right? So how to move on? Do we first introduce the new location in selinux-policy and then update the location in default config? Thank you for any further pointers!
(In reply to Marcel Haerry from comment #8) > thanks for the hints. It should be doable to move the location, we might > need to apply a patch, but that should be fine. > > But still, we would need ~/.config/google-authenticator to be correctly > labled first, right? So how to move on? Do we first introduce the new > location in selinux-policy and then update the location in default config? > Thank you for any further pointers! Coordinated steps are the best approach. If you are sure about the config directory name, we can update the selinux policy and backport the change to all supported Fedora versions.
Isn't this a the same as 1767606?
John: bug 1767606 seems to be specific to cockpit (though the underlying problem is the same). Also there was bug 754978 which is mostly the same as this issue. Maybe we should even consider fixing this upstream (google authenticator could use a different location)? Are there other Fedora developers interested in fixing this? Personally I would like to get 2FA with GDM working and I'm ready to spend some cycles getting this fixed properly (though I would like to connect with someone from the SELinux team + potentially someone with experience in the g-a/GDM code).
There is consensus how to fix upstream (see https://github.com/google/google-authenticator-libpam/issues/101#issuecomment-725685946 and following comments). BUT somebody needs to come up with a patch.
Oliver: Why did you mark this as needinfo? This needs a fix upstream.
Felix, I have a specific question to Zdenek if we want to track this separately for RHEL 8 as well.
Oliver, This bug has been created for Fedora for the google-authenticator component. Once the path is changed in g.a. and backed with appropriate selinux-policy adjustments, RHEL bzs need to be created, possibly cloned from existing Fedora bzs.
Ack Zdenek. Since I ran into that issue myself with RHEL 8, let me know if I can be of help in some way (later).
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
I have the same issue with Fedora 33 Server-Edition. Tested login with temporarily disabled SElinux which worked fine. Login with enabled SElinux results in the given permission errors and prevents the user to login. Both ssh and cockpit.
Bug opened for CentOS 8, still present on CentOS (8 AppStream) and after 1y still OPEN. Nice work. Better discussing the sex of angels, to make O.S. more inclusive, than fixing and closing bugs of SSO.
(In reply to Giandomenico De Tullio from comment #20) > Bug opened for CentOS 8, still present on CentOS (8 AppStream) and after 1y > still OPEN. This needs a fix upstream and nobody so far picked up the work upstream to get it fixed: https://github.com/google/google-authenticator-libpam/issues/101#issuecomment-725685946 > Nice work. > Better discussing the sex of angels, to make O.S. more inclusive, than > fixing and closing bugs of SSO. Are you able to contribute upstream to get it implemented? Otherwise, such comments do not help in any way to motivate folks to contribute and I'd like to ask you to keep such comments for yourself.
๐ https://github.com/google/google-authenticator-libpam/issues/101#issuecomment-997533681
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Still exists on Fedora 35 Server Edition.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.