Bug 1840113

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.