Previous Entry Share Next Entry
SELinux versus pam_google_authenticator...
I just became aware of a new PAM, pam_google_authenticator.

It is some kind of One TIme Password tool to allow you to add One Time Passwords to you Linux Login and I guess use your Android phone.

pam_google_authenticator causes login programs to  try and  write to ~/.google_authenticator by default.  SELinux does not like this.  SELinux prevents login programs from writing to random locations in the home directory.  It is usually not a good idea to rely on stuff in the home dir for authorization because the homedir may require authorization to be able to be mounted or decrypted. (kNFS for example).  

I got a bugzilla on sshd not being able to write to ~/.google_authenticator.  One option would be to set the label on the .google_authenticator as ssh_home_t.  I also did some "googling" and found the following entry:

Comment by phil.may <snip>, Jul 7, 2011

If you are using Fedora and SELinux, you will need to use the right config. The default SELinux policy does not allow the SSH daemon to update the ~/.google_authenticator file.

In Fedora 14 (and possibly other versions) sshd runs under "sshd_t" and can only writelocations with certain SELinux labels. One such label is "var_auth_t" and the default policy sets this label on "/var/run/user/" Therefore, the following config works:

# If the user is NOT in group "otp_users", skip next module
auth [success=1 default=ignore] user notingroup otp_users
auth       required secret=/var/run/user/${USER}/.google_authenticator
auth       include      password-auth

BTW I have not tried this out on Fedora 16, and am curious if this will work, or does pam_google_authenticator expect the contents of .google_authenticator to survive a reboot.

  • 1

I'm actually the person who left the comment above; I've been successfully using pam_google_authenticator with the .file in /var/run/user/${USER} for a while now. However, there is one thing to be aware of:

The init scripts on Fedora seem to empty /var/run/user on boot or shutdown. Therefore, after a reboot, you can't login, and it doesn't fail with a sensible error message - it just drops you back to a login/gdm prompt :o(

I solved this with an entry in /etc/rc.local which copies the file into place on boot, but it's hacky and it's clear why - /var/run/user isn't really meant for these kinds of files.

Yes I just checked in some fixes to allow sshd and other login programs to edit ~/.google_authorization file.

I have a couple more questions within the bugzilla, and then will probably update the blog. I might have jumped the gun. :^(

  • 1

Log in