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

Al Biheiri - abiheiri@gmail

Dan are you suggesting that we set .google_authenticator as ssh_home_t on a per user basis?

meaning :
semanage fcontext -a -t ssh_home_t "/home/user01/.google_authenticator(/.*)?"
semanage fcontext -a -t ssh_home_t "/home/user02/.google_authenticator(/.*)?"

and so on?

The output of audit2allow seems to suggest to allow sshd_t a larger set of access to user_home_dir_t..
I suppose your method is more fine grained in that sense

root@jh:/home/toor/policies# ausearch -m avc -ts today|audit2allow

#============= sshd_t ==============
allow sshd_t user_home_dir_t:dir { write remove_name add_name };
allow sshd_t user_home_dir_t:file { rename write getattr read create unlink open };
allow sshd_t user_home_t:file { read getattr unlink open };

Re: Al Biheiri - abiheiri@gmail

user_home_dir_t is the top level of the home directory, No directories/files within the homedir should ever be labeled user_home_dir_t. I guess the best label for now on .google_authenticator is ssh_home_t. Allow sshd_t to read/write any files within the homedir is what we are trying to avoid.

  • 1

Log in

No account? Create an account