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. :^(

I love this blog. I've been setting up seLinux (which I also love, BTW!) and it keeps striking me how unfairly selinux has been maligned as difficult. It *is* complex, but so is keeping things secure. Technologies like sVirt make my paranoid sysadmin's heart go pitter-pat. And when I need help, I depend on blogs like this. (The standard documentation is probably the least friendly part of seLinux.)

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.

I have found that simply setting ~/.google_authenticator to ssh_home_t still causes AVC denials when updates to the file occur as write requests come in for user_home_dir_t ~/.google_authenticator~

I've tried adding both paths using semanage but found that still did not appear to resolve it.

As I use google authenticator mainly for SSH I simply moved the file into ~/.ssh/ after applying the change with

auth required secret=/home/${USER}/.ssh/.google_authenticator

the directory permission issues went away.

This was all tested on CentOS 6.x



I have fixed this problem in Fedora 17

Basically .google_authenticator~ and .google_authenticator will be created with the correct context.

  • 1

Log in