+++ This bug was initially created as a clone of Bug #168180 for RHEL4 +++ Description of problem: Version-Release number of selected component (if applicable): all pam with the SELinux patch included (FC3,4 RHEL4) How reproducible: Try: $ echo -n <root password> | /sbin/unix_chkpwd root nonull && echo OK OK should not be printed. So the problem is in this part of SELinux patch: /* - * determine the current user's name is + * determine the current user's name is. + * On a SELinux enabled system, policy will prevent third parties from using + * unix_chkpwd as a password guesser. Leaving the existing check prevents + * su from working, Since the current uid is the users and the password is + * for root. */ - user = getuidname(getuid()); - if (argc == 2) { - /* if the caller specifies the username, verify that user - matches it */ - if (strcmp(user, argv[1])) { - force_failure = 1; - } + if (SELINUX_ENABLED) { + user=argv[1]; + } + else { + user = getuidname(getuid()); + /* if the caller specifies the username, verify that user + matches it */ + if (strcmp(user, argv[1])) { + return PAM_AUTH_ERR; + } + } Obviously when you set SELinux to permissive mode it's possible to run unix_chkpwd without problem. But even when I set it to enforcing I was able to run it. (Probably it's disabled only by strict policy?) So unix_chkpwd allows brute-forcing of any passwords in /etc/shadow. Also note that there is no delay if the password is incorrect - it exits immediately, and there is no logging of failed attempts.
Created attachment 118806 [details] Add delay to unix_chkpwd on failure. Here is a patch that adds a 2 second delay after failure if SELinux is called. Similar to what would happen if you called su. Only problem with this patch is it will double timeout of other apps using pam's delay function. Also this does not prevent user from doing a verify unix_chkpwd root verify < /dev/null 12959:0:99999:7:-1:-1 Which I am not sure is a security problem.
I'd prefer to remove the if(SELINUX_ENABLED) part of the original patch for RHEL4 as we don't ship strict policy for RHEL4. Then we can think about and test a better patch for a next update release.
A simple fix for this would be if (SELINUX_ENABLED && 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])) { + return PAM_AUTH_ERR; + } + } This app will only be run as root when SELinux is blocking access to the /etc/shadow. I believe this fixes the problem with out changing the behavior at all.
This is what I propose too but it would work only if the setuid(0) call was added after the fork before exec-ing unix_chkpwd in pam_unix module. Otherwise su, sudo, userhelper won't work (they call setuid later in the process).
Please see also bug 168180 for discussion.
Lifting embargo, this issue is now public.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-805.html
Installing the official RHEL4 pam-0.77-66.13 from this errata breaks subversion-via-httpd's ability to use pam_unix for authentication. Specifically: I'm running RHEL AS4 for 32-bit x86. When I install the updated pam rpm, I'm no longer able to use pam_unix to authenticate mod_dav_svn. I get the following error in /var/log/messages when attempting to login with a subversion client: Nov 15 19:56:25 dev httpd(pam_unix)[31001]: authentication failure; logname= uid=48 euid=48 tty= ruser= rhost= user=jay (UID 48 is the apache login.) Rolling back to pam-0.77-66.11 solves the problem. I have no problem using pam_unix to authenticate regular web directories, only subversion repositories, which seems like a good clue. I don't know enough to know if this is a bug in the errata, or a bug in the way mod_dav_svn works. Maybe it doesn't ask for the right privileges, but the former pam bug was letting it get away with that? If so, I will report to the subversion team. I'm running Apache httpd 2.0.54, installed from source, with subversion 1.2.3, likewise. Snippets of my httpd.conf: ..the regular web site, which works fine... <Directory "/srv/www/htdocs/my.site.example.com"> Options +Indexes IndexIgnore .. SSLRequireSSL AuthPAM_Enabled On AuthType Basic AuthName "Development Intranet" Require valid-user </Directory> ..the subversion repository, which fails as soon as the errata RPM is installed... <VirtualHost *:443> ServerName svn.example.com CustomLog logs/svn.access.log combined SSLEngine On # This must be accessible, but is otherwise unused DocumentRoot "/srv/www/htdocs/svn-phony" <Location /dev/> AuthPAM_Enabled on AuthType Basic AuthName "Developer repository" Require group dev </Location> <Location /> DAV svn SVNParentPath "/srv/svn/" SVNPathAuthz off </Location> </VirtualHost> .. my /etc/pam.d/httpd config ... #%PAM-1.0 auth required /lib/security/pam_unix.so account required /lib/security/pam_unix.so
This was never intended to work - for example if you've had turned SELinux off with the previous pam release it wouldn't work either. It is not too good idea to authenticate httpd against unix accounts and passwords anyway. Couldn't the subversion via httpd be authenticating against its own password database? Of course if you don't care about security too much you can make /etc/shadow readable for the apache group or not to use shadow passwords at all although I wouldn't recommend doing anything like that.