• 1
Hey,

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 pam_google_authenticator.so secret=/home/${USER}/.ssh/.google_authenticator

the directory permission issues went away.

This was all tested on CentOS 6.x

Cheers,

Sam

I have fixed this problem in Fedora 17

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

  • 1
?

Log in