Closed mihaigalos closed 6 months ago
Related: https://github.com/google/google-authenticator-libpam/issues/105.
6y later. The setuid
proposal is still relevant.
Confirmed working with:
chown root:root ~/.google_authenticator
and:
-auth required pam_google_authenticator.so [authtok_prompt=Authenticator token: ]
+auth required pam_google_authenticator.so secret=/home/${USER}/.google_authenticator user=root [authtok_prompt=Authenticator token: ]
In this case you probably don't want the file in the user's home directory. Probably place it in /etc/google-authenticator/${USER}
or something, instead.
I don't think it should be a security issue, as the PAM module aims to check that the user didn't delete the original file and replace it with an attacker-chosen one. But I would still not recommend putting a root-owned file in the user's home directory.
If you want to secure sudo
, may I also recommend https://github.com/ThomasHabets/sim ?
Is your feature request related to a problem? Please describe. Once a potential attacker gets access to a host which has pam-authenticated sudo access, that attacker is half-way there to gaining root. That's because if they can already remotely execute a read on the
~/.google_authenticator
file, they can generate OTPs using the contents of the file.The default
~/.google_authenticator
file should therefore be protected against reading by the current user (0400 but owned by root).Describe the solution you'd like Potentially make
.google_authenticator
be owned by root and run the pam authentication privileged, so as to be able to read the file.Describe alternatives you've considered
Additional context Naively tried a
chown root:root ~/.google_authenticator
thensudo ls
, the pam module stopped working (the .google_authenticator file could not be read, according to journalctl).Here's my
/etc/pam.d/sudo
: