This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 220085 - LSPP - vsftpd denies local logins when system is enforcing mls policy
LSPP - vsftpd denies local logins when system is enforcing mls policy
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
: OtherQA, Reopened
Depends On:
Blocks: RHEL5LSPPCertTracker
  Show dependency treegraph
 
Reported: 2006-12-18 15:16 EST by Klaus Heinrich Kiwi
Modified: 2010-10-22 03:28 EDT (History)
7 users (show)

See Also:
Fixed In Version: RHBA-2007-0544
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 11:37:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 29661 None None None Never

  None (edit)
Description Klaus Heinrich Kiwi 2006-12-18 15:16:54 EST
Description of problem:
local users cannot login to vsftpd server when system is enforcing MLS policy.
The deamon denies the login with '530 - login incorrect'. AVC messages shows
failed attempts to access the /var/log/tallylog (pam_tally and pam_tally 2 shows
no failed attempts for any user)

This bug is critical to the LSPP certification - and it is currently locking the
resolution of bug RIT107824 

Version-Release number of selected component (if applicable):
Using RHEL5 beta2 2006-12-07 refresh, lspp .57 kernel - i386

relevant package version follows:
[root@rhel5lspp ~]# rpm -qa | egrep 'policy|kernel|ftp|selinux|pam'
pam_passwdqc-1.0.2-1.2.2
libselinux-1.33.2-1.el5
pam_ccreds-3-5
libselinux-devel-1.33.2-1.el5
selinux-policy-2.4.6-14.el5
pam-devel-0.99.6.2-3.8.el5
selinux-policy-targeted-2.4.6-14.el5
kernel-headers-2.6.18-1.2839.el5
ftp-0.17-33.fc6
libselinux-python-1.33.2-1.el5
policycoreutils-1.33.6-3.el5
pam_pkcs11-0.5.3-23
pam_krb5-2.2.11-1
lftp-3.5.1-2.fc6
vsftpd-2.0.5-8
policycoreutils-newrole-1.33.6-3.el5
pam-0.99.6.2-3.8.el5
kernel-2.6.18-1.2840.2.1.el5.lspp.57
selinux-policy-devel-2.4.6-14.el5
selinux-policy-strict-2.4.6-14.el5
checkpolicy-1.33.1-2.el5
pam_smb-1.1.7-7.2.1
kernel-devel-2.6.18-1.2840.2.1.el5.lspp.57
selinux-policy-mls-2.4.6-14.el5
[root@rhel5lspp ~]#

vsftpd configuration:
[root@rhel5lspp ~]# cat /etc/vsftpd/vsftpd.conf | egrep -v "^#.*"
anonymous_enable=YES
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
listen=YES

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
[root@rhel5lspp ~]#


How reproducible:
always

Steps to Reproduce:
1. System needs to be using MLS policy in enforcing mode
2. make sure 'local_enable' is set to 'yes' in vsftpd.conf
3. run_init /etc/init.d/vsftpd [re]start
4. ftp localhost
5. <enter user>
6. <enter password>
  
Actual results:
login denial:
530 Login incorrect.
Login failed.

==AVC messages====
type=AVC msg=audit(1166471322.965:324): avc:  denied  { getattr } for  pid=1980
comm="vsftpd" name="tallylog" dev=dm-2 ino=23
scontext=system_u:system_r:ftpd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:faillog_t:s0 tclass=file

type=SYSCALL msg=audit(1166471322.965:324): arch=40000003 syscall=196 success=no
exit=-13 a0=189010 a1=bf93071c a2=306ff4 a3=93b08c0 items=0 ppid=1942 pid=1980
auid=502 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
comm="vsftpd" exe="/usr/sbin/vsftpd"
subj=system_u:system_r:ftpd_t:s0-s15:c0.c1023 key=(null)

type=AVC_PATH msg=audit(1166471322.965:324):  path="/var/log/tallylog"

type=AVC msg=audit(1166471322.969:325): avc:  denied  { append } for  pid=1980
comm="vsftpd" name="tallylog" dev=dm-2 ino=23
scontext=system_u:system_r:ftpd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:faillog_t:s0 tclass=file

type=SYSCALL msg=audit(1166471322.969:325): arch=40000003 syscall=5 success=no
exit=-13 a0=189010 a1=8441 a2=1b6 a3=93b6908 items=0 ppid=1942 pid=1980 auid=502
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="vsftpd"
exe="/usr/sbin/vsftpd" subj=system_u:system_r:ftpd_t:s0-s15:c0.c1023 key=(null)

type=USER_AUTH msg=audit(1166471326.554:326): user pid=1980 uid=0 auid=502
subj=system_u:system_r:ftpd_t:s0-s15:c0.c1023 msg='PAM: authentication
acct=ealuser : exe="/usr/sbin/vsftpd" (hostname=rhel5lspp.example.com,
addr=127.0.0.1, terminal=ftp res=failed)'


Expected results:
to be able to log-in

Additional info:
Probably just need to add { getattr }  and { append }  permission to
/var/log/tallylog
Comment 1 Daniel Walsh 2006-12-18 15:40:00 EST
Fixed in selinux-policy-2.4.6-15
Comment 4 Klaus Heinrich Kiwi 2006-12-22 08:59:55 EST
Confirmed fix against 1218 refresh - thanks for the quick response!

 -Klaus
Comment 7 RHEL Product and Program Management 2007-02-07 20:52:57 EST
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.
Comment 9 Klaus Weidner 2007-02-12 23:25:50 EST
Please reopen, I can't confirm that this is fixed. I get the following AVC
message which seems to indicate that full read/write access is needed by vsftpd:

type=AVC msg=audit(1171086936.240:433): avc:  denied  { read write } for 
pid=2220 comm="vsftpd" name="tallylog" dev=dm-2 ino=6146
context=system_u:system_r:ftpd_t:s0-s15:c0.c1023
tcontext=system_u:object_r:faillog_t:s0 tclass=file

The way I understand pam_tally2 to work is that it seeks to a file position
based on the numerical UID and updates the failure information there in place. 

Unless I'm mistaken, vsftpd will need:

   auth_rw_faillog(ftpd_t)
Comment 11 Daniel Walsh 2007-02-14 13:32:46 EST
Fixed in selinux-policy-2.4.6-38
Comment 13 Klaus Heinrich Kiwi 2007-02-21 08:03:04 EST
Testing still awaiting for .el5 package
Comment 14 Daniel Walsh 2007-02-21 11:00:26 EST
Should be on people now.  Sorry about that.
Comment 15 Klaus Heinrich Kiwi 2007-03-20 11:42:26 EDT
seems fixed, you can close the bug
Comment 24 errata-xmlrpc 2007-11-07 11:37:58 EST
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-2007-0544.html

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