Bug 383191 - pam-0.99.6.2-3.26.el5 breaks vsftp login under selinux
pam-0.99.6.2-3.26.el5 breaks vsftp login under selinux
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-14 14:33 EST by Gilles Detillieux
Modified: 2008-05-21 12:06 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0465
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 12:06:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
strace output from vsftpd child process during login (21.80 KB, text/plain)
2007-11-14 15:56 EST, Gilles Detillieux
no flags Details

  None (edit)
Description Gilles Detillieux 2007-11-14 14:33:53 EST
Description of problem:
Since the pam-0.99.6.2-3.26.el5 errata update, vsftp no longer allows
non-anonymouns logins.  Reverting to the original 0.99.6.2-3.14 release makes
the problem go away.

Version-Release number of selected component (if applicable):
0.99.6.2-3.26.el5

How reproducible:
Always.

Steps to Reproduce:
1. Install pam-0.99.6.2-3.26.el5 update on RHEL5.
2. "ftp localhost", and login using an unprivileged username and password.
3. Look at error messages, then "setenforce 0" and repeat step 2 for a
successful login.
4. "setenforce 1", then step 2 fails again.
5. revert to pam-0.99.6.2-3.14 and step 2 succeeds again.
  
Actual results:
FTP client gives these errors after the user enters the password:
530 Login incorrect.
Login failed.

/var/log/secure shows these log entries:
Nov 14 13:05:43 dave2 unix_chkpwd[21242]: could not get username from shadow
(grdetil))
Nov 14 13:05:43 dave2 vsftpd: pam_unix(vsftpd:account): unix_update returned error 9

/var/log/audit/audit.log shows a log entry like this one, but no AVC messages
are logged:
type=USER_ACCT msg=audit(1195067023.947:3979): user pid=21228 uid=0
auid=4294967295 subj=system_u:system_r:ftpd_t:s0 msg='PAM: accounting
acct=grdetil : exe="/usr/sbin/vsftpd" (hostname=dave2.scrc.umanitoba.ca,
addr=140.193.80.133, terminal=ftp res=failed)'


Expected results:
A successful login, as with the pam-0.99.6.2-3.14 release, or with setenforce 0.


Additional info:
1. The RHSA-2007:0555-8 security advisory says this:

* pam_unix module security properties were improved. Functionality in the
setuid helper binary, unix_chkpwd, which was not required for user
authentication, was moved to a new non-setuid helper binary, unix_update.

A look at the patches in the SRPM for the new release shows some pretty
substantial changes to unix_chkpwd and pam_unix.  I suspect one of these changes
introduced the problem.

2. I've set the boolean option in selinux for vsftpd to be allowed access to
users' home directories.
Comment 1 Gilles Detillieux 2007-11-14 14:42:39 EST
I should also add that the same login username works fine under ssh.  I've
compared /etc/pam.d/sshd to /etc/pam.d/vsftpd, and noticed that /etc/pam.d/sshd
contained the line:

password   include      system-auth

while /etc/pam.d/vsftpd didn't.  I tried adding that line, but it didn't make a
difference.
Comment 2 Tomas Mraz 2007-11-14 15:15:03 EST
Can you please attach a strace from vsftpd, when you try to log in? Do not use
valuable password.
Comment 3 Gilles Detillieux 2007-11-14 15:56:57 EST
Created attachment 258821 [details]
strace output from vsftpd child process during login
Comment 4 Tomas Mraz 2007-11-14 16:12:53 EST
The process is running with correct uid so the problem is in the selinux-policy.
Probably there is not a proper transition from ftpd_t to another context
allowing reading /etc/shadow during the exec of unix_update.

Note that the message 'unix_chkpwd[21242]: could not get username from shadow
(grdetil)' is actually misleading and coming from unix_update not from
unix_chkpwd - this is a small bug in unix_update.
Comment 5 Gilles Detillieux 2007-11-14 16:56:09 EST
OK, I'm a bit confused by this.  I thought unix_update was split out of
unix_chkpwd, for updating a password in /etc/shadow, and had nothing to do with
checking passwords.  Why would pam_unix call unix_update to verify my password?
 I thought that job remained with unix_chkpwd.  What does vsftpd need to update
that sshd doesn't?

I did this...
   chcon system_u:object_r:chkpwd_exec_t /sbin/unix_update
and now FTP logins work.  But I guess next time some process does a restorecon
in /sbin, that change will be reversed (back to sbin_t).

It's odd that the failure of unix_update to execute, or to do its job (whatever
that might be) after it executed, didn't generate any AVC message in audit.log.

Is there anything else you'd like me to try, or should I just wait for a
selinux-policy update to make the change permanent?  Is chkpwd_exec_t even the
correct selinux context for unix_update, or did I just open (or re-open) a hole
by doing that?  In any case, I think it's probably better than staying with the
old version of pam, and certainly better than turning off selinux enforcing.

Thanks for looking into this.
Comment 6 Daniel Walsh 2007-11-15 08:56:24 EST
What version of selinux-policy are you running?
Comment 7 Gilles Detillieux 2007-11-15 14:15:25 EST
selinux-policy-targeted-2.4.6-30.el5 currently.  I see there's an update release available, 
according to RHBA-2007:0544, but my system doesn't have it yet.  I'll look into it.
Comment 8 Daniel Walsh 2007-11-16 10:01:57 EST
Yes please update to nux-policy-targeted-2.4.6-106.el5-1.3
Comment 9 Gilles Detillieux 2007-11-16 13:42:04 EST
Done.  Works like a charm now.  vsftpd is happy, and so am I.  Thanks for your
help and sorry to waste your time.  I'll pay closer attention to the errata next
time and make sure I have ALL the updates.
Comment 10 RHEL Product and Program Management 2008-01-30 14:15:35 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 15 errata-xmlrpc 2008-05-21 12:06:06 EDT
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/RHBA-2008-0465.html

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