Bug 754978

Does

chcon -t ssh_home_t -R /root/.google_authenticator

Fix your problem?

A little googling I found:

Comment by phil.may..., 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 write locations 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] pam_succeed_if.so user notingroup otp_users
auth       required     pam_google_authenticator.so secret=/var/run/user/${USER}/.google_authenticator
auth       include      password-auth

Re: comment #1
It helps a little - the PAM module can see the .google_authenticator file now, asks for the verification code (= TOTP), but then authentication fails with error message

sshd(pam_google_authenticator)[11977]: Failed to update secret file "/root/.google_authenticator"

It apparently does not rewrite the file directly, but tries to create /root/.google_authenticator~ and then rename it, which (as you can probably guess ;-) fails with the following AVC:

type=AVC msg=audit(1321630548.779:1470): avc:  denied  { create } for  pid=11979 comm="sshd" name=".google_authenticator~" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:admin_home_t:s0 tclass=file

Re: comment #2
Yes, of course, this works (which I have mentioned in the last paragraph of this bug report). I was just suggesting that this location should either be the default in pam_g_a, or the policy should be fixed (i.e., pam_g_a should work out of the box). What do you think about it?

David would changing the pam entry line in the /usr/share/doc/google-authenticator-0/README to indicate to use the secret=/var/run/user/${USER}/.google_authenticator line.

Re: comment #2
/var/run is not a good location at all, as it gets cleaned up after reboot.

Yes I have continued to investigate it.  It looks like it needs to be able to read/write the .google_authenticator file. When it writes this file does it write it directly.

Miroslav I added 
11578593e78aea26fe858b91a7c928b0705e7d74

This to F17, need back port to F16 to handle this.  

My only concern is if pam_google_authenticator creates a temporary file in ~ and then renames over .google_authenticator

Using ~/.google_authenticator is entirely stupid.

See http://code.google.com/p/google-authenticator/issues/detail?id=51

My patch from that upstream bug is present in the Fedora package.

David why not make that the default /var/lib/google-authenticator/${USER}

Then make the tool and the examples point to this directory.  Currently while users can user alternative locations, they usually go with the default.

google-authenticator 
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/dwalsh@redsox%3Fsecret%3DW4H62KM3U5YJTYNF
Your new secret key is: W4H62KM3U5YJTYNF
Your verification code is 829371
Your emergency scratch codes are:
  32816989
  88614473
  24814369
  33190058
  88245540

Do you want me to update your "~/.google_authenticator" file (y/n) y

Using /var/lib/<user-owned-directory> would lead into problems with disk quotas. What about ${HOME}/.google-authenticator/data or something like that?

Of course every part of the pacage including /usr/bin/google-authenticator and documentation should be updated to the default location, after it is decided what location it should be.

Does a user have to be able to write to this file?  Or just the login programs?

I was thinking to have /var/lib/google-authenticator/dwalsh  But the file owned by root.

Currently there is a patch to have authconfig to setup /etc/google-authenticator/dwalsh

738879

Putting the file in the users homedir, has multiple problems for security to nfs to encrypted file system.  As David has pointed out.

Doesn't the /usr/bin/google-authenticator need access to this file?

Maybe we can look how fingerprint readers (fprintd and pam_fprintd.so) solve the same problem.

Yes and I would argue that should be run by an administrator when he is setting up the pam stack.

Yes, but also the user should be able to run it - for example when the user (nearly) runs out of emergency scratch codes or when his phone is stolen/lost/reinstalled.

In that case I guess I would suggest that the program be setgid and still write to a system file.  This would eliminate the ability for other apps/processes from reading the authorization data.

It's not optimal for the behaviour of the Fedora package to differ significantly from upstream; I'd much rather get that fixed upstream first.

I'd also like to fix the default behaviour of /usr/bin/google-authenticator to match, and that would mean making it setuid and adding an authentication mechanism (like the way that passwd(8) asks for your old password first).

That sounds good to me. 

David what I don't necessarily understand is the following.

allow sshd_t admin_home_t:file { rename write getattr read create unlink open
};

This means that sshd is writing to the file or some file in the homedir, I guess when the user logs in.  Does every login program have to rewrite the .google_authorization file?  Or should this be separated out into two different files?  User sets up the initial secrets, which the login programs read, and then they write to some cache file?

Daniel: this is probably in order to prevent replay attack or TOTP guessing.

David: is upstream open to the discussion wrt. the location of the data file?

Yes. If the DISALLOW_REUSE option is set then the last successful key is stored in the file. The one-time keys are also deleted if they are used.

Upstream doesn't seem to be responding at all, unfortunately. While I'd *like* to get changes upstream before shipping them, my *main* reason for not changing the default (yet) is because we haven't changed /usr/bin/google-authenticator to match. That requires some careful security design (well, implementation at least. The design should follow passwd(8) I think).

This needs to work for both ssh and other login programs, yes. Most notably, gdm.

kup-0.3-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kup-0.3-2.fc16

Bleh. Bad copy-paste of bug #. Please ignore. Sorry!

I was configuring this for chfn, just for testing, and it also does not work. Clearly the problem is beyond just login programs.

Please note that the PAM module 1.0 is already released into Google code, you should use that instead of dealing with Mercurial:
http://code.google.com/p/google-authenticator/downloads/list

I tested the new Google library and everything works as intended, in a secured root environment. David Woodhouse highlights very well the issues, I detail them further into my tutorial:
http://www.axivo.com/go/googleauth

Redhat developers should release a proper package and also create a new version for authconfig to support Google Authenticator for all branches (i.e. CentOS 5 and 6). PAM standards should be applied, for example the package should be named pam_google_authenticator (not google-authenticator) and Selinux should have ssh_home_t signed the /var/lib/google-authenticator directory.

To test my packages for CentOS/Redhat 64bits (5 or 6 releases), install the repo of your choice and follow the instructions posted into above mentioned tutorial link.

Axivo Repository: http://rpm.axivo.com

Regards,

Floren Munteanu

What ever the resolution of the debate over where to put the auth files (come on now, we allow users to have their own auth files for ssh authorized_keys in their home directory) the packages that are in Fedora right through rawhide are woafully out of date and just a year old git snapshot long before they released 1.0.  That snapshot is missing pieces like the nullok option.

Whatever upstream does or doesn't do, what we have is not good.  I would personally like to recommend this to some of our management as a viable alternative to RSA tokens but not in the state it's in now.

It's in Rawhide now and been in several releases but it's old.  Can't we at least get parity, warts and all, even if we don't get the toots and whistles we would like, like the authconfig integration?  It's better than what's there now, even if it's not perfect, and it might stir up some much needed interest.

(In reply to comment #26)
> authorized_keys in their home directory) the packages that are in Fedora
> right through rawhide are woafully out of date and just a year old git
> snapshot long before they released 1.0.  That snapshot is missing pieces
> like the nullok option.

It's probably worth filing a request for an updated package set as a separate issue, so we can keep this about the SELinux support.

Good suggestion.  Submitted.

https://bugzilla.redhat.com/show_bug.cgi?id=850618

I have to raise an objection to some of the suggestions mentioned above.  I've gone back and reread the entire thread and must object that you must not and can not use any location under /var for this.  The reason being is that this is authentication information which may be applicable to root and a non-negligible number of systems have /var on another partition or even network mounted.  This could make is unavailable for authentication for root when /var is not mounted (i.e. single user mode).  It's bad enough that we are now forced to merge certain classical separations between / and /usr because of these sorts of needs.  We really must avoid a hard requirement of forcing /var to be mounted as well.  That leaves not just /var/run unusable for the arguments above but also /var/lib/google-authenticator.  This is authentication information.  It belongs in /etc.

Personally, I still believe the proper location to save the user data is /var/lib/google-authenticator. By the book, the /etc hierarchy contains configuration files while /var/lib hierarchy holds state information pertaining to an application or the system, more exactly data that programs modify while they run and pertains to one specific host. Which is exactly the case for TOTP files. The only /etc location needed is something like /etc/pam.d/google-authenticator, matched with a proper authconfig patch.

The further complete the above statement: State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. State information should generally remain valid after a reboot, should not be logging output, and should not be spooled data.

I think "must be available even when only / is mounted" is pretty compelling, and it's probably worth interpretting "the book" as generously as possible to make that possible.

Can you please further detail the above statement, Matthew? I'm not sure I understand, thank you.

Well, see comment #29; it seems like an important concern.

Particularly, an advantage of this particular two-factor system over many other options is that it doesn't have a network component and so could be used for things like root console access (assuming other physical security). Making it require /var to be mounted makes that less robust.

I understand. What about similar /var/lib locations, like /var/lib/{authconfig,mysql,rpm,yum} and so on? They are dependent on root accessing the data the same way TOTP would, right? Basically, you propose to have a /etc/google-authenticator directory when all user auth files are stored.

I would like to hear David Woodhouse's opinion on this. Personally, I've been dealing with Redhat for a while and the only network /var/lib mounted directory is always /var/lib/mysql.

(In reply to comment #35)
> I understand. What about similar /var/lib locations, like
> /var/lib/{authconfig,mysql,rpm,yum} and so on? They are dependent on root
> accessing the data the same way TOTP would, right?

The concern isn't that root needs to access files, but that the files need to be available in repair situations so that authentication can be done (usually by the root user). Making a separate /var is still a supported and relatively common case.

Thank you for the further explanation, Matthew. So what would be the proposed location? I'm following closely this discussion because I write my own RPM's and provide them as yum alternative until Redhat includes Google Authenticator into their releases. Hopefully, David will chim into discussion.

I think /etc/google-authenticator/ is a reasonable choice. /etc/security/google-authenticator would be fine too. 

Have you considered becoming a Fedora contributor? David is a relatively busy person and I bet he'd be open to adding a co-maintainer.

Sure, I could contribute to Fedora packages. I have a lot of experience with RPM's but I don't know what is the proper way to apply for a maintainer position.

https://fedoraproject.org/wiki/PackageMaintainers/Join — and we can take this conversation offline if you would like more help — feel free to e-mail me.

Thank you, I submitted a package review.
https://bugzilla.redhat.com/show_bug.cgi?id=850949

I have to raise an objection to some of the suggestions mentioned above.  I've gone back and reread the entire thread and must object that you must not and can not use any location under /var for this.  The reason being is that this is authentication information which may be applicable to root and a non-negligible number of systems have /var on another partition or even network mounted.  This could make is unavailable for authentication for root when /var is not mounted (i.e. single user mode).  It's bad enough that we are now forced to merge certain classical separations between / and /usr because of these sorts of needs.  We really must avoid a hard requirement of forcing /var to be mounted as well.  That leaves not just /var/run unusable for the arguments above but also /var/lib/google-authenticator.  This is authentication information.  It belongs in /etc.

Floren:

Cool.  I've plulled your srpm down and will test it myself on F15 (I know, I know - I still do testing on it), F16, and F17 myself.  I've already referred a number of people where I work to your tutorial.  Your package built just fine under F15 and I'm about to try it under the others along with few other platforms and varients...

Did run into one problem.  The files it creates conflict with the files google_authenticator from the Fedora and EPEL repos.  You might want to consider an "Obsoletes:" in the spec.

I'm almost wondering if this file location shouldn't be specified out of a build configuration option like the configure --statedir= or something like many others of the rpm packages.  We still would have to deal with things like creating subdirectories, a group name, and all that for setup...

I do agree that the manual steps to move that out of the user directory is definitely suboptimal and it still remains to integrate this with authconfig.

Hi Michael,

I will add pam-authenticator package as obsolete into spec file, that should be taken care of any conflicts.

Ah, wth...  Comment 42 is a dup of an earlier comment.  I don't know if my browser did that on a refresh or bugzilla did that.  Apologies.

I re-uploaded the new source package with obsoleted google-authenticator.

(In reply to comment #43)
> I'm almost wondering if this file location shouldn't be specified out of a
> build configuration option like the configure --statedir= or something like
> many others of the rpm packages.  We still would have to deal with things
> like creating subdirectories, a group name, and all that for setup...

I think this could be easily managed by authconfig. pam_google_authenticator should provide ONLY the module, nothing else. I believe this is the approach used by any other modules, while authconfig does the base setup.

Well, the trouble with google-authenticator as a 2-factor authn solution is 2-fold (pun not intended):

1. The same process that reads the secret out of the file needs to write to the same file -- in order to prevent replay attacks and to do things like rate-limiting. That's a terrible design choice -- it's like allowing your password-checking application to write to /etc/shadow.
2. The same secret file cannot be used on multiple machines, as this makes it vulnerable to replay attacks. E.g. if you have serverA and serverB and install the same secret file in serverA:/etc/google-authenticator/user and serverB:/etc/google-authenticator/user, then as long as the attacker is able to sniff the token you used to authenticate to serverA, they can reuse it on serverB, within the token's lifetime window. To avoid this, you'd need to use a different token per each host, and that just doesn't scale.

Google-authenticator was designed to be run on 1 system by 1 user -- out of their home directory. If you need to scale this up to multiple servers you need to separate the secret data from the state data and use a central host in order to make it a true one-time password.

This is the reason I wrote totpcgi: https://github.com/mricon/totp-cgi. Now we just need to thoroughly review pam_url and package it nicely. :)

(In reply to comment #48)
> 2. The same secret file cannot be used on multiple machines, as this makes
> it vulnerable to replay attacks.
IMO, using the same TOTP file on different servers is totally illogical, no sane server admin would accept that. If a user wants to login into a specific box on the network, the admin has the choice to enable the TOTP login into main access server or through each server he/she wants to further secure. As user attempting a connection from external location, you cannot login to a specific node unless you are coming through the gateway entrance node. Simple and efficient.

> Google-authenticator was designed to be run on 1 system by 1 user -- out of
> their home directory.
Which is the intended use for this application. I want to protect a specific entrance door into my network, not the hole shebang. Well, you can... but I want to see an admin who will do that in the first place.

(In reply to comment #49)
> IMO, using the same TOTP file on different servers is totally illogical, no
> sane server admin would accept that. If a user wants to login into a
> specific box on the network, the admin has the choice to enable the TOTP
> login into main access server or through each server he/she wants to further
> secure. As user attempting a connection from external location, you cannot
> login to a specific node unless you are coming through the gateway entrance
> node. Simple and efficient.

Yes, that's a solution as long as you are terminating idle connections. Otherwise your internal network is only as secure as your users' workstations.

My interest is primarily requiring 2-factor for sudo, not for ssh.

(In reply to comment #50)
> My interest is primarily requiring 2-factor for sudo, not for ssh.

Thank you for clarifying. I would be interested to find out why do you think is convenient to use the TOTP tokens with sudo.

(In reply to comment #50)
> (In reply to comment #49)
> > IMO, using the same TOTP file on different servers is totally illogical, no
> > sane server admin would accept that. If a user wants to login into a
> > specific box on the network, the admin has the choice to enable the TOTP
> > login into main access server or through each server he/she wants to further
> > secure. As user attempting a connection from external location, you cannot
> > login to a specific node unless you are coming through the gateway entrance
> > node. Simple and efficient.
> 
> Yes, that's a solution as long as you are terminating idle connections.
> Otherwise your internal network is only as secure as your users'
> workstations.
> 
> My interest is primarily requiring 2-factor for sudo, not for ssh.

* Warning...  This is going to get off topic but I feel it's worth pointing out.

Actually, in my mind, using this for sudo is the wrong answer, or at least a weaker answer, especially on servers.  I feel that using "pam-ssh-agent-auth" and requiring strong authentication keys is a better solution for sudo.  In fact, that module was designed specifically with sudo in mind.  If the person is remote, you don't even have ANY secret keying material on the server at all, only the public authorized keys, which you have stored in a secured location.  This can be locked down even further.  It works for both local user sudo and remote user sudo using ssh auth agent forwarding.

Again, in my mind, IMNSHO, using google-authenticator to manage the local logins and providing strong identity keys and/org certs for remote access is a superior answer for those challenges.

I have a use-case where we want to have sudo issue an identity challenge on every use. Right now, we're using proprietary RSA SecurID for this and it would be nice to migrate away. Konstantin's solution looks nice but has a lot of moving parts; part of the appeal of this module is that it's small and self contained.

(In reply to comment #53)
> I have a use-case where we want to have sudo issue an identity challenge on
> every use. Right now, we're using proprietary RSA SecurID for this and it
> would be nice to migrate away. Konstantin's solution looks nice but has a
> lot of moving parts; part of the appeal of this module is that it's small
> and self contained.

And THAT is a valid answer.  You have a legitimate, defined use case.

I'm in a similar situation where I want to relace spotty use of expensive RSA tokens with more widespread use of this system, including things like Cisco ASA VPNs (OpenConnect and/or VPNC IPsec), which are going to be problematical in more ways than one!  This is just the tip of my iceburg.

After we manage to get this straightened out, then I have to go after the NetworkMangler people because NM and its plugins can not do this (found that out trying to register RSA token PINS).  They don't seem to have any structure for a double prompt for the challenge auth.  You only get one bite at the apple so RSA tokens work because you don't use your password, you prepend the auth code from the token with your PIN.  This requires you enter a password and then get prompted a second time for your auth verification code.  That breaks the NM paradigm.  But that's another fight in another group even assuming we (my team and my developers) can figure out how to make this work with the Cisco ASAs and OpenConnect or VPNC, in the first place.  :-/

(In reply to comment #53)
> Konstantin's solution looks nice but has a
> lot of moving parts; part of the appeal of this module is that it's small
> and self contained.

Well, you have to have these moving parts if you want to separate the process that reads the secret from the process that wants to write to the same file. You add more moving parts if you want to scale it beyond one-secret-per-user-per-system and keep the "One-Time" part of the "TOTP" definition.

However, all the moving pieces are well understood -- totpcgi requires little other than a webserver capable of running cgi and doing mutual SSL authentication. You can also use a RADIUS server intermediate to plug it into your existing SecurID infrastructure. There is a RADIUS script included as part of the contrib directory.

Totpcgi also comes with a simple provisioning infrastructure that can provision tokens.

(In reply to comment #55)
> Well, you have to have these moving parts if you want to separate the
> process that reads the secret from the process that wants to write to the
> same file. You add more moving parts if you want to scale it beyond
> one-secret-per-user-per-system and keep the "One-Time" part of the "TOTP"
> definition.

Absolutely. That was not meant as a criticism, just a contrast. (Harvard's Research Computing is taking a similar approach using RADIUS.)

(In reply to comment #48)
> Well, the trouble with google-authenticator as a 2-factor authn solution is
> 2-fold (pun not intended):
> 
> 1. The same process that reads the secret out of the file needs to write to
> the same file -- in order to prevent replay attacks and to do things like
> rate-limiting. That's a terrible design choice -- it's like allowing your
> password-checking application to write to /etc/shadow.
> 2. The same secret file cannot be used on multiple machines, as this makes
> it vulnerable to replay attacks. E.g. if you have serverA and serverB and
> install the same secret file in serverA:/etc/google-authenticator/user and
> serverB:/etc/google-authenticator/user, then as long as the attacker is able
> to sniff the token you used to authenticate to serverA, they can reuse it on
> serverB, within the token's lifetime window. To avoid this, you'd need to
> use a different token per each host, and that just doesn't scale.
> 
> Google-authenticator was designed to be run on 1 system by 1 user -- out of
> their home directory. If you need to scale this up to multiple servers you
> need to separate the secret data from the state data and use a central host
> in order to make it a true one-time password.
> 
> This is the reason I wrote totpcgi: https://github.com/mricon/totp-cgi. Now
> we just need to thoroughly review pam_url and package it nicely. :)

Perhaps so.  But, I have to agree with Mathew.  Now, I'm personally not a big fan of web gui interfaces.  The fact that you are compatible with Google Authenticator is nice and all but we also need this working properly and this is core.  Personally, I would not deploy your solution in my environment.  Not to say anything bad about it, quite the contrary, it just would not fit in with my environment at this time.  We need to solve this first and then look at what you have that can integrate with / enhance it.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.