Comments - PAM Authentication Plugin

4 years, 9 months ago hartmut-php

I needed to add the "mysql" user to the "shadow" group in /etc/group to make simple pam_unix based authentication work, without that i just got this in /var/log/auth.log :

Jul 4 12:16:45 hartmut-laptop2 unix_chkpwd[7446]: check pass; user unknown Jul 4 12:16:45 hartmut-laptop2 unix_chkpwd[7446]: password check failed for user (hartmut)

 
3 years, 9 months ago serg

This happens if you have old PAM installation, newer ones have a suid utility unix_chkpwd, and don't require the client application to be able to read /etc/shadow

 
3 years, 6 months ago shanew

Can someone clarify "new" vs. "old" PAM?

I'm running 1.1.6, and I had to do the same as hartmut-php to make this work. It's better than running Maria as root, but still doesn't seem like it should be necessary to use pam_unix.

 
3 years, 6 months ago serg

Interesting. What distribution are you using? Is it stock unmodified pam as it comes with your distribution?

 
3 years, 6 months ago shanew

This is the standard 1.1.6 (r2) ebuild on Gentoo. /sbin/unix_chkpwd is 711 with setuid, as expected. The relevant log entries are:

Sep 30 14:51:04 hostname mysqld: pam_warn(mysql:auth): function=[pam_sm_authenticate] service=[mysql] terminal=[<unknown>] user=[shanew] ruser=[<unknown>] rhost=[<unknown>]
Sep 30 14:51:04 hostname unix_chkpwd[3430]: check pass; user unknown
Sep 30 14:51:04 hostname unix_chkpwd[3430]: password check failed for user (shanew)
Sep 30 14:51:04 hostname mysqld: pam_unix(mysql:auth): authentication failure; logname=root uid=60 euid=60 tty= ruser= rhost= user=shanew

Gentoo doesn't have a shadow group by default, so I had to create one, add mysql to it, and then alter ownership/perms on /etc/shadow accordingly.

 
3 years, 6 months ago serg

Very interesting. I'm using sys-libs/pam-1.1.6-r2 on Gentoo. And I don't have a shadow group. Still, I don't need hartmut's workaround, pam module works for me just fine.

 
3 years, 6 months ago shanew

Could it be a MariaDB version issue, as the system I'm testing this on is only at 5.2.14? I also ran into the fact that PHP (which was rebuilt after MariaDB was installed) doesn't seem to know how to talk to the dialog plugin via mysqli, so I'm likely going to have to upgrade MariaDB anyway.

 
3 years, 6 months ago shanew

Alternately, what seems to work is the following:
Add a shadow group;
Chgrp /etc/shadow to shadow & chmod to 640;
Chgrp on /sbin/unix_chkpwd to shadow & chmod so that it's -rwsr-sr-x;

Whether this is more or less secure than adding the mysql user to the shadow group, I'm not entirely sure.

Note that this scheme is borrowed from Ubuntu 12.04 LTS.

 
2 years, 5 months ago hartmut-php

Doesn't work for me (Ubuntu 14.10, Ubuntu distribution MariaDB packages)

"Problem" is that unix_chkpwd explicitly checks that its UID matches the username given as cmdline argument, *unless* the UID is 0 (root). As it checks UID, not EUID, suid chmod magic doesn't make a difference here.

The related check code in unix_chkpwd.c is at https://git.fedorahosted.org/cgit/linux-pam.git/tree/modules/pam_unix/unix_chkpwd.c#n129

if (getuid() == 0) { user=argv[1]; } else { user = getuidname(getuid()); /* if the caller specifies the username, verify that user matches it */ if (strcmp(user, argv[1])) { user = argv[1]; /* no match -> permanently change to the real user and proceed */ if (setuid(getuid()) != 0) return PAM_AUTH_ERR; } }

So unless mysqld is running as root the "does the given user name match my UID?" check will only succeed if the mysql user name matches the system user name, e.g. usually pam_unix will work for mysql users "mysql@..." if mysqld is running as unix user "mysql"

 
2 years, 5 months ago serg

I'm thinking of a solution to this (and other similar problems): MDEV-7032

 
2 years, 5 months ago hartmut-php

Well, the "can only check the users own password unless invoked by root" limitation is there for a reason:

as unix_chkpwd is a local binary and not a service it can be used to perform brute force dictionary attacks against /etc/shadow without a need to have read access to the shadow file otherwise ...

Restricting access to this for root isn't necessary as root can read the shadow file (and other things like changing user passwords) anyway ...

But for any other user starting unix_chkpwd extra care is taken that only the password of this single user can be cracked this way (again not that much harm with this as an attacker must somehow gained access to that user account already anyway)

Any shadow entry for other users are still hidden by the inner working of unix_chkpwd

(adding some comments on MDEV-7032, too ..)

 
2 years, 5 months ago hartmut-php

unix_chkpwd does throttle on wrong credentials being passed in, but that only helps if it is part of a service toolchain as it is with pam_unix

when called directly an attacker doesn't have to wait for the 10s penalty after giving a wrong password but can just start new unix_chkpwd processes without anything putting artificial limits on the number of checks per time unit ...

 
Loading