Comments - Authentication Plugin - PAM

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)

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

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.

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

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.

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.

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.

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.

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"

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

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 ..)

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 ...