This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 754978 - design of pam_google_authenticator does not work with Fedora's SELinux security model
design of pam_google_authenticator does not work with Fedora's SELinux securi...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: google-authenticator (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-18 08:15 EST by Jan "Yenya" Kasprzak
Modified: 2015-02-18 06:07 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 06:07:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jan "Yenya" Kasprzak 2011-11-18 08:15:07 EST
Description of problem:
google authenticator stores by default its authentication data in ~/.google_authenticator. It needs permissions to read and write this file (because of one-time scratch keys, etc.). SSH-daemon is not allowed to do this under current selinux policy.

Version-Release number of selected component (if applicable):
selinux-policy-3.10.0-55.fc16.noarch
selinux-policy-targeted-3.10.0-55.fc16.noarch
google-authenticator-0-0.2.20110830.hgd525a9bab875.fc16.x86_64

How reproducible:
100 %

Steps to Reproduce:
1. as root, install google-authenticator, and configure it:
   - run "google-authenticator" to setup the secret
   - install the Google Authenticator app to your smartphone, and add the secret from the previous step
   - in /etc/pam.d/password-auth change pam_unix.so from sufficient to required
   - in the same file, add "auth sufficient pam_google_authenticator.so" after pam_unix.so line
2. try to log in using ssh to the root account using password, not a SSH key pair
  
Actual results:
The authentication process fails (the Password: prompt is displayed again); in /var/log/secure the following message is addedd:
sshd(pam_google_authenticator)[11740]: Failed to read "/root/.google_authenticator


Expected results:
After the password prompt, pam_g_a.so should display the "Verification code:" prompt.


Additional info:
With "setenforce 0" it works as expected. Audit2allow suggests the following change to the policy:

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

I don't think it is reasonable - I think ~/.google_authenticator file should have its own type.

An alternative solution (making pam_g_a.so store its secrets in a different directory) is discussed here:
http://code.google.com/p/google-authenticator/wiki/PamModuleInstructions
but I think in that case it should become the default location in Fedora (feel free to requalify this bug as a google-authenticator bug then).
Comment 1 Daniel Walsh 2011-11-18 10:11:33 EST
Does

chcon -t ssh_home_t -R /root/.google_authenticator

Fix your problem?
Comment 2 Daniel Walsh 2011-11-18 10:28:13 EST
A little googling I found:

Comment by phil.may...@gmail.com, 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
Comment 3 Jan "Yenya" Kasprzak 2011-11-18 10:43:52 EST
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?
Comment 4 Daniel Walsh 2011-11-18 10:53:11 EST
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.
Comment 5 Jan "Yenya" Kasprzak 2011-11-18 10:53:39 EST
Re: comment #2
/var/run is not a good location at all, as it gets cleaned up after reboot.
Comment 6 Daniel Walsh 2011-11-18 11:25:48 EST
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
Comment 7 David Woodhouse 2011-11-18 12:04:17 EST
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.
Comment 8 Daniel Walsh 2011-11-18 12:58:56 EST
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
Comment 9 Jan "Yenya" Kasprzak 2011-11-18 13:08:59 EST
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.
Comment 10 Daniel Walsh 2011-11-18 13:17:09 EST
Does a user have to be able to write to this file?  Or just the login programs?
Comment 11 Daniel Walsh 2011-11-18 13:19:24 EST
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.
Comment 12 Jan "Yenya" Kasprzak 2011-11-18 13:41:10 EST
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.
Comment 13 Daniel Walsh 2011-11-18 13:47:36 EST
Yes and I would argue that should be run by an administrator when he is setting up the pam stack.
Comment 14 Jan "Yenya" Kasprzak 2011-11-18 14:05:37 EST
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.
Comment 15 Daniel Walsh 2011-11-18 14:20:04 EST
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.
Comment 16 David Woodhouse 2011-11-18 15:06:05 EST
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).
Comment 17 Daniel Walsh 2011-11-18 15:23:09 EST
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?
Comment 18 Jan "Yenya" Kasprzak 2011-11-18 15:30:03 EST
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?
Comment 19 David Woodhouse 2011-11-18 15:47:01 EST
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).
Comment 20 Konstantin Ryabitsev 2011-11-21 12:53:36 EST
This needs to work for both ssh and other login programs, yes. Most notably, gdm.
Comment 21 Fedora Update System 2011-11-21 13:43:44 EST
kup-0.3-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/kup-0.3-2.fc16
Comment 22 Konstantin Ryabitsev 2011-11-21 13:44:33 EST
Bleh. Bad copy-paste of bug #. Please ignore. Sorry!
Comment 23 Matthew Miller 2012-04-27 14:07:05 EDT
I was configuring this for chfn, just for testing, and it also does not work. Clearly the problem is beyond just login programs.
Comment 24 Floren Munteanu 2012-08-08 00:06:11 EDT
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
Comment 25 Floren Munteanu 2012-08-08 03:47:37 EDT
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
Comment 26 Michael H. Warfield 2012-08-21 16:01:26 EDT
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.
Comment 27 Matthew Miller 2012-08-21 16:26:12 EDT
(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.
Comment 28 Michael H. Warfield 2012-08-21 22:14:42 EDT
Good suggestion.  Submitted.

https://bugzilla.redhat.com/show_bug.cgi?id=850618
Comment 29 Michael H. Warfield 2012-08-22 09:46:35 EDT
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.
Comment 30 Floren Munteanu 2012-08-22 14:37:49 EDT
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.
Comment 31 Floren Munteanu 2012-08-22 14:43:39 EDT
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.
Comment 32 Matthew Miller 2012-08-22 14:51:29 EDT
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.
Comment 33 Floren Munteanu 2012-08-22 15:04:54 EDT
Can you please further detail the above statement, Matthew? I'm not sure I understand, thank you.
Comment 34 Matthew Miller 2012-08-22 15:17:13 EDT
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.
Comment 35 Floren Munteanu 2012-08-22 15:26:40 EDT
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.
Comment 36 Matthew Miller 2012-08-22 15:37:21 EDT
(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.
Comment 37 Floren Munteanu 2012-08-22 15:43:01 EDT
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.
Comment 38 Matthew Miller 2012-08-22 15:56:51 EDT
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.
Comment 39 Floren Munteanu 2012-08-22 16:01:01 EDT
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.
Comment 40 Matthew Miller 2012-08-22 16:02:53 EDT
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.
Comment 41 Floren Munteanu 2012-08-22 16:36:35 EDT
Thank you, I submitted a package review.
https://bugzilla.redhat.com/show_bug.cgi?id=850949
Comment 42 Michael H. Warfield 2012-08-22 16:53:57 EDT
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.
Comment 43 Michael H. Warfield 2012-08-22 17:11:50 EDT
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.
Comment 44 Floren Munteanu 2012-08-22 17:14:30 EDT
Hi Michael,

I will add pam-authenticator package as obsolete into spec file, that should be taken care of any conflicts.
Comment 45 Michael H. Warfield 2012-08-22 17:20:28 EDT
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.
Comment 46 Floren Munteanu 2012-08-22 17:32:23 EDT
I re-uploaded the new source package with obsoleted google-authenticator.
Comment 47 Floren Munteanu 2012-08-22 17:45:43 EDT
(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.
Comment 48 Konstantin Ryabitsev 2012-08-23 01:50:54 EDT
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. :)
Comment 49 Floren Munteanu 2012-08-23 02:11:46 EDT
(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.
Comment 50 Konstantin Ryabitsev 2012-08-23 02:18:23 EDT
(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.
Comment 51 Floren Munteanu 2012-08-23 02:28:18 EDT
(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.
Comment 52 Michael H. Warfield 2012-08-23 08:42:59 EDT
(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.
Comment 53 Matthew Miller 2012-08-23 08:49:46 EDT
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.
Comment 54 Michael H. Warfield 2012-08-23 10:33:56 EDT
(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.  :-/
Comment 55 Konstantin Ryabitsev 2012-08-23 13:16:28 EDT
(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.
Comment 56 Matthew Miller 2012-08-23 13:28:50 EDT
(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.)
Comment 57 Michael H. Warfield 2012-08-23 13:32:22 EDT
(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.
Comment 58 Fedora End Of Life 2013-04-03 16:25:23 EDT
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
Comment 59 Fedora End Of Life 2015-01-09 17:30:07 EST
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.
Comment 60 Fedora End Of Life 2015-02-18 06:07:36 EST
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.

Note You need to log in before you can comment on or make changes to this bug.