Description of problem: If glusterfs-fuse mount is used for the ftp data directory, the vsftpd process is prevented from accessing the content by SELinux. Version-Release number of selected component (if applicable): selinux-policy-targeted-2.4.6-338.el5 selinux-policy-2.4.6-338.el5 How reproducible: Steps to Reproduce: 1. Set up a Red Hat Storage (RHS) server to provide a glusterfs volume, with the data to be provided by the ftp server 2. Mount the glusterfs volume on a RHEL 5 system, using glusterfs-fuse mount, under '/var/ftp/' and start vsftpd service 3. The data provided through the glusterfs volume is not accessible over ftp --------------------------------------------------------------- # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.9 (Tikanga) # df -Th /var/ftp/RHS/ Filesystem Type Size Used Avail Use% Mounted on glusterfs#RHSvm05:/AppStore fuse 360G 3.6G 357G 1% /var/ftp/RHS # ls -Zd /var/ftp/ drwxr-xr-x root root system_u:object_r:public_content_t /var/ftp/ # ls -Zd /var/ftp/RHS/ drwxr-xr-x root root system_u:object_r:fusefs_t /var/ftp/RHS/ =========================== type=AVC msg=audit(1363988130.223:51): avc: denied { getattr } for pid=10108 comm="vsftpd" path="/RHS" dev=fuse ino=1 scontext=root:system_r:ftpd_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir type=SYSCALL msg=audit(1363988130.223:51): arch=c000003e syscall=6 success=no exit=-13 a0=2aec75909670 a1=2aec75909690 a2=2aec75909690 a3=0 items=0 ppid=10106 pid=10108 auid=0 uid=14 gid=50 euid=14 suid=14 fsuid=14 egid=50 sgid=50 fsgid=50 tty=(none) ses=1 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=root:system_r:ftpd_t:s0 key=(null) type=AVC msg=audit(1363988135.359:52): avc: denied { search } for pid=10108 comm="vsftpd" name="/" dev=fuse ino=1 scontext=root:system_r:ftpd_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir type=SYSCALL msg=audit(1363988135.359:52): arch=c000003e syscall=80 success=no exit=-13 a0=2aec759013e0 a1=226 a2=2aec5dbb856c a3=2 items=0 ppid=10106 pid=10108 auid=0 uid=14 gid=50 euid=14 suid=14 fsuid=14 egid=50 sgid=50 fsgid=50 tty=(none) ses=1 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=root:system_r:ftpd_t:s0 key=(null) --------------------------------------------------------------- Additional Points: 1) If the 'allow_ftpd_full_access' SELinux boolean is turned on, the access to the glusterfs data is still NOT allowed. This is different from the behaviour on RHEL 6, where the access is allowed, when the SELinux boolean is turned on. --------------------------------------------------------------- type=MAC_CONFIG_CHANGE msg=audit(1363988194.256:53): bool=allow_ftpd_full_access val=1 old_val=0 auid=0 ses=1 type=USER_AVC msg=audit(1363988194.262:54): user pid=2014 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0 msg='avc: received policyload notice (seqno=3) : exe="?" (sauid=81, hostname=?, addr=?, terminal=?)' type=SYSCALL msg=audit(1363988194.256:53): arch=c000003e syscall=1 success=yes exit=2 a0=4 a1=7fff03444490 a2=2 a3=6e6172746e79645f items=0 ppid=2257 pid=10123 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=1 comm="setsebool" exe="/usr/sbin/setsebool" subj=root:system_r:semanage_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1363988202.232:55): avc: denied { getattr } for pid=10128 comm="vsftpd" path="/RHS" dev=fuse ino=1 scontext=root:system_r:ftpd_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir type=SYSCALL msg=audit(1363988202.232:55): arch=c000003e syscall=6 success=no exit=-13 a0=2aec75909690 a1=2aec759096b0 a2=2aec759096b0 a3=0 items=0 ppid=10126 pid=10128 auid=0 uid=14 gid=50 euid=14 suid=14 fsuid=14 egid=50 sgid=50 fsgid=50 tty=(none) ses=1 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=root:system_r:ftpd_t:s0 key=(null) type=AVC msg=audit(1363988277.343:56): avc: denied { search } for pid=10128 comm="vsftpd" name="/" dev=fuse ino=1 scontext=root:system_r:ftpd_t:s0 tcontext=system_u:object_r:fusefs_t:s0 tclass=dir type=SYSCALL msg=audit(1363988277.343:56): arch=c000003e syscall=80 success=no exit=-13 a0=2aec75901400 a1=226 a2=2aec5dbb856c a3=2 items=0 ppid=10126 pid=10128 auid=0 uid=14 gid=50 euid=14 suid=14 fsuid=14 egid=50 sgid=50 fsgid=50 tty=(none) ses=1 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=root:system_r:ftpd_t:s0 key=(null) --------------------------------------------------------------- 2) If the glusterfs volume is mounted over nfs, and the 'allow_ftpd_use_nfs' SELinux boolean is turned on, the access to the glusterfs data is allowed. I believe that a new SELinux boolean 'allow_ftpd_use_fusefs', with the required allow rules, is desirable, to have this access allowed. Actual results: vsftpd (ftpd_t) cannot access content stored in a gluster volume, mounted using gluster-fuse (fusefs_t) mount method. Expected results: vsftpd (ftpd_t) should be able to access content stored in a gluster volume, mounted using gluster-fuse (fusefs_t) mount method. Additional info:
I added fixes to Fedora. Will back port.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
vsftpd cannot read symlinks located on FUSE filesystem right now. Do your scenarios involve symlinks?
(In reply to Milos Malik from comment #7) > vsftpd cannot read symlinks located on FUSE filesystem right now. Do your > scenarios involve symlinks? No, my test scenarios currently do not involve symlinks
In my opinion ftpd_use_fusefs boolean should allow a FTP daemon to access symbolic links too. It's only a matter of time before somebody creates a symlink on FUSE filesystem and FTP daemon tries to access it.
(In reply to Milos Malik from comment #9) > In my opinion ftpd_use_fusefs boolean should allow a FTP daemon to access > symbolic links too. It's only a matter of time before somebody creates a > symlink on FUSE filesystem and FTP daemon tries to access it. Though my current scenario did not include symbolic links, I agree with you that it would be fairly common for the use case to pop up later. Especially if it is currently allowed on RHEL6, then we might as well have it here as well. On a security point of view, if the symbolic link goes to a directory having SELinux context that is barred for the FTP daemon, that access would be anyway blocked, I believe. So opening up access to symbolic links for the FTP daemon should be fine. - rejy (rmc)
Fixed in selinux-policy-2.4.6-343.el5
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1312.html