[OATH-Toolkit-help] Fw: One Time Password in SLiM

[Christian Hesse]

Hello everybody,

I'm trying to get pam_oath to work with any graphical login manager...
Just wrote this mail to the SLiM mailing list:

--- Begin forwarded message ---
Date: Fri, 29 Apr 2011 13:17:06 +0200
From: Christian Hesse <***@eworm.de>
To: slim-***@lists.berlios.de
Subject: One Time Password in SLiM

Hello everybody!

I've used SLiM for some time now and I am very happy with it.

Recently I bought a hardware one time password token. PAM is set up
(using pam_oath.so from OATH Toolkit [0]) and everything works fine with
login, su and ssh.

However it does not work with SLiM.
I added pam_oath.so to /etc/pam.d/slim and tried to log in. The values
in /etc/users.oath change, so pam returns success I think. But SLiM
does not let me in, it beeps and asks for the password again.

Does SLim Support this kind of authentication?

[0] http://www.nongnu.org/oath-toolkit/
--- End forwarded message ---

The next test was xscreensaver... Did not work as well. I got the
dialog with username and "One-time pass...", but it fails. Here's the
log from xscreensaver -no-splash -verbose:

pam_start ("xscreensaver", "eworm", ...) ==> 0 (Success)
pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success)
pam_authenticate (...) ...
pam_conversation (ECHO_OFF="One-time password (OATH) for `eworm':
") ... 0: mouse is at 608,311.
0: creating password dialog ("")
grabbing server...
0: ungrabbing mouse (was 0xb1).
0: grabbing mouse on 0xa00015... GrabSuccess.
ungrabbing server.
input finished.
pam_conversation (...) ==> PAM_SUCCESS
pam_authenticate (...) ==> 7 (Authentication failure)
pam_end (...) ==> 0 (Success)
All authentication mechanisms failed.
syslog: FAILED LOGIN 1 ON DISPLAY ":0.0", FOR "eworm"
0: creating password dialog ("Authentication failed!")

Possibly this is an issue by pam_oath.so and not the graphical tools...
Any ideas?

[Christian Hesse]

Post by Christian Hesse
Possibly this is an issue by pam_oath.so and not the graphical tools...
Any ideas?

KDM works... So we have issues in SLiM and xscreensaver.
Anyway - any ideas? :D

[Christian Hesse]

Post by Christian Hesse

Post by Christian Hesse
Possibly this is an issue by pam_oath.so and not the graphical tools...
Any ideas?

KDM works... So we have issues in SLiM and xscreensaver.
Anyway - any ideas? :D

I've fixed SLiM! :D
Take a look at this bug report, including the fix:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=15287&group_id=2663

xscreensaver to go...

[Christian Hesse]

Post by Christian Hesse
xscreensaver to go...

This is gonna be kind of monologue... :D

Ok, here are the new facts: Authentication succeeds if I add 'alwaysok' to
pam_oath. So the communication between xscreensaver and pam_oath is ok. Does
the pam module have a problem accessing the usersfile? xscreensaver is run
as user (uid 1000 or something...).

This is the debug output:
[pam_oath.c:parse_cfg(118)] called.
[pam_oath.c:parse_cfg(119)] flags 0 argc 3
[pam_oath.c:parse_cfg(121)] argv[0]=usersfile=/etc/users.oath
[pam_oath.c:parse_cfg(121)] argv[1]=debug
[pam_oath.c:parse_cfg(121)] argv[2]=alwaysok
[pam_oath.c:parse_cfg(122)] debug=1
[pam_oath.c:parse_cfg(123)] alwaysok=1
[pam_oath.c:parse_cfg(124)] try_first_pass=0
[pam_oath.c:parse_cfg(125)] use_first_pass=0
[pam_oath.c:parse_cfg(126)] usersfile=/etc/users.oath
[pam_oath.c:parse_cfg(127)] digits=0
[pam_oath.c:parse_cfg(128)] window=5
[pam_oath.c:pam_sm_authenticate(157)] get user returned: eworm
[pam_oath.c:pam_sm_authenticate(232)] conv returned: 123456
[pam_oath.c:pam_sm_authenticate(292)] OTP: 123456
[pam_oath.c:pam_sm_authenticate(303)] authenticate rc -11 last otp Thu Jan 1
01:00:00 1970
[pam_oath.c:pam_sm_authenticate(309)] One-time password not authorized to
login as user 'eworm'
[pam_oath.c:pam_sm_authenticate(322)] alwaysok needed (otherwise return with
7)
[pam_oath.c:pam_sm_authenticate(325)] done. [Success]

[Simon Josefsson]

Post by Christian Hesse

Post by Christian Hesse
xscreensaver to go...

This is gonna be kind of monologue... :D
Ok, here are the new facts: Authentication succeeds if I add 'alwaysok' to
pam_oath. So the communication between xscreensaver and pam_oath is ok. Does
the pam module have a problem accessing the usersfile? xscreensaver is run
as user (uid 1000 or something...).

...

Post by Christian Hesse
[pam_oath.c:pam_sm_authenticate(303)] authenticate rc -11 last otp Thu Jan 1
01:00:00 1970

-11 means OATH_NO_SUCH_FILE, i.e., the usersfile could not be
found/opened. The usersfile is normally owned by root and no other has
access. It could be a configuration error, how does your xscreensaver
PAM line look like? How does xscreensaver/pam_unix solve this for
e.g. /etc/shadow? Doesn't xscreensaver have to be setuid-root for
things to work?

Btw, I find your "monologue" interesting, it is the kind of feedback
that is important -- we don't know where pam_oath works without someone
testing it and reporting about it.

/Simon

[Christian Hesse]

Post by Simon Josefsson

Post by Christian Hesse

Post by Christian Hesse
xscreensaver to go...

This is gonna be kind of monologue... :D
Ok, here are the new facts: Authentication succeeds if I add 'alwaysok' to
pam_oath. So the communication between xscreensaver and pam_oath is ok.
Does the pam module have a problem accessing the usersfile? xscreensaver
is run as user (uid 1000 or something...).

...

Post by Christian Hesse
[pam_oath.c:pam_sm_authenticate(303)] authenticate rc -11 last otp Thu
Jan 1 01:00:00 1970

-11 means OATH_NO_SUCH_FILE, i.e., the usersfile could not be
found/opened. The usersfile is normally owned by root and no other has
access.

It is. ;) Surely this file should not be world readable.

Post by Simon Josefsson
It could be a configuration error, how does your xscreensaver
PAM line look like?

It's the same line I user for slim, su, ...

Post by Simon Josefsson
How does xscreensaver/pam_unix solve this for
e.g. /etc/shadow? Doesn't xscreensaver have to be setuid-root for
things to work?

No, xscreensaver is not set setuid-root. Usually it does not need to if it
uses pam. pam_unix has a little helper program /sbin/unix_chkpwd. This one is
setuid-root. Do we need something like that as well?

Post by Simon Josefsson
Btw, I find your "monologue" interesting, it is the kind of feedback
that is important -- we don't know where pam_oath works without someone
testing it and reporting about it.

:D

[Christian Hesse]

Hello everybody,

some more comments on this.

Post by Simon Josefsson
-11 means OATH_NO_SUCH_FILE, i.e., the usersfile could not be
found/opened.

Would be nice to get human readable output here. I spent a lot of time
searching for the problem, a simple "Could not read usersfile." would be of
great help.

Post by Simon Josefsson
How does xscreensaver/pam_unix solve this for e.g. /etc/shadow?

I took a deeper look at pam_unix and unix_chkpwd. pam_unix always calls
unix_chkpwd via execev() to authenticate the user.
I'm not sure I could implement this for pam_oath... Is anybody willing to do
this? I will take a deeper look if I have some spare time.

[Simon Josefsson]

Post by Christian Hesse
Hello everybody,
some more comments on this.

Post by Simon Josefsson
-11 means OATH_NO_SUCH_FILE, i.e., the usersfile could not be
found/opened.

Would be nice to get human readable output here. I spent a lot of time
searching for the problem, a simple "Could not read usersfile." would be of
great help.

The next release will make you happy. :-)

I added oath_strerror and oath_strerror_name functions, the PAM module
will now print lines like this instead:

[pam_oath.c:pam_sm_authenticate(305)] authenticate rc -6 (OATH_INVALID_OTP: The OTP is not valid) last otp Sun May 1 22:57:21 2011
[pam_oath.c:pam_sm_authenticate(305)] authenticate rc -8 (OATH_BAD_PASSWORD: The password does not match) last otp Thu Jan 1 01:34:13 1970
[pam_oath.c:pam_sm_authenticate(305)] authenticate rc 0 (OATH_OK: Successful return) last otp Sun May 1 22:57:21 2011

See commits at:

http://git.savannah.gnu.org/cgit/oath-toolkit.git/commit/?id=fba5affe8873ed88b8d931594e9abbec742559b8
http://git.savannah.gnu.org/cgit/oath-toolkit.git/commit/?id=0971e08e9bcb226148da90c24e493473c1c89de0

You can run the self-test to print all error codes and descriptions if
you give it a parameter:

***@latte:~/src/oath-toolkit master$ liboath/tests/tst_errors foo
Return code 3 name: (null) text: Liboath unknown error
Return code 2 name: (null) text: Liboath unknown error
Return code 1 name: (null) text: Liboath unknown error
Return code 0 name: OATH_OK text: Successful return
Return code -1 name: OATH_CRYPTO_ERROR text: Internal error in crypto functions
Return code -2 name: OATH_INVALID_DIGITS text: Unsupported number of OTP digits
Return code -3 name: OATH_PRINTF_ERROR text: Error from system printf call
Return code -4 name: OATH_INVALID_HEX text: Hex string is invalid
Return code -5 name: OATH_TOO_SMALL_BUFFER text: The output buffer is too small
Return code -6 name: OATH_INVALID_OTP text: The OTP is not valid
Return code -7 name: OATH_REPLAYED_OTP text: The OTP has been replayed
Return code -8 name: OATH_BAD_PASSWORD text: The password does not match
Return code -9 name: OATH_INVALID_COUNTER text: The counter value is corrupt
Return code -10 name: OATH_INVALID_TIMESTAMP text: The timestamp is corrupt
Return code -11 name: OATH_NO_SUCH_FILE text: The supplied filename does not exist
Return code -12 name: OATH_UNKNOWN_USER text: Cannot find information about user
Return code -13 name: OATH_FILE_SEEK_ERROR text: System error when seeking in file
Return code -14 name: OATH_FILE_CREATE_ERROR text: System error when creating file
Return code -15 name: OATH_FILE_LOCK_ERROR text: System error when locking file
Return code -16 name: OATH_FILE_RENAME_ERROR text: System error when renaming file
Return code -17 name: OATH_FILE_UNLINK_ERROR text: System error when removing file
Return code -18 name: OATH_TIME_ERROR text: System error for time manipulation
Return code -19 name: (null) text: Liboath unknown error
Return code -20 name: (null) text: Liboath unknown error
Return code -21 name: (null) text: Liboath unknown error
***@latte:~/src/oath-toolkit master$

/Simon

[Simon Josefsson]

Post by Christian Hesse

Post by Simon Josefsson
How does xscreensaver/pam_unix solve this for e.g. /etc/shadow?

I took a deeper look at pam_unix and unix_chkpwd. pam_unix always calls
unix_chkpwd via execev() to authenticate the user.
I'm not sure I could implement this for pam_oath... Is anybody willing to do
this? I will take a deeper look if I have some spare time.

We could add a setuid wrapper to do this, but I wonder if there aren't
better solutions. I can't immediately think of any good solution
though... maybe a system-wide daemon running that some client code
could talk to? That is a bit complex though.

/Simon

[Christian Hesse]

Post by Christian Hesse

Post by Simon Josefsson
How does xscreensaver/pam_unix solve this for e.g. /etc/shadow?

I took a deeper look at pam_unix and unix_chkpwd. pam_unix always calls
unix_chkpwd via execev() to authenticate the user.
I'm not sure I could implement this for pam_oath... Is anybody willing to do
this? I will take a deeper look if I have some spare time.

Nothing happened to make pam_oath work with xscreensaver and the like
(non-root services), no?

Ok, some thoughts on that... pam_oath.so should not link to liboath.so but
call a little helper program. The latter is linked against liboath.so and set
uid root to access the usersfile.
Is that the correct way or do we need to do it different?

[Simon Josefsson]

Post by Christian Hesse

Post by Christian Hesse

Post by Simon Josefsson
How does xscreensaver/pam_unix solve this for e.g. /etc/shadow?

I took a deeper look at pam_unix and unix_chkpwd. pam_unix always calls
unix_chkpwd via execev() to authenticate the user.
I'm not sure I could implement this for pam_oath... Is anybody willing to do
this? I will take a deeper look if I have some spare time.

Nothing happened to make pam_oath work with xscreensaver and the like
(non-root services), no?

Not that I recall.

Post by Christian Hesse
Ok, some thoughts on that... pam_oath.so should not link to liboath.so but
call a little helper program. The latter is linked against liboath.so and set
uid root to access the usersfile.
Is that the correct way or do we need to do it different?

Yes, that sounds like a possible way forward. I don't like setuid
binaries though. A daemon approach may be safer, but that is more
complex and doesn't work if the daemon isn't always running. If you
want to work on a setuid helper that would be very nice. It could be
used when some PAM configuration token is present, right?

/Simon

[Jean-Michel Pouré - GOOZE]

Post by Christian Hesse
This is gonna be kind of monologue... :D

Dont't worry, we are ready you with great interest.