Bug 1362716
| Summary: | selinux avc denial for vsftp login as ipa user | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Scott Poore <spoore> |
| Component: | sssd | Assignee: | Lukas Slebodnik <lslebodn> |
| Status: | CLOSED ERRATA | QA Contact: | Steeve Goveas <sgoveas> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | CC: | grajaiya, jhrozek, lslebodn, lvrabec, mgrepl, mkolaja, mkosek, mmalik, mzidek, pbrezina, plautrba, pvrabec, spoore, ssekidde |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | sssd-1.14.0-35.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-04 07:20:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Just to hopefully explain what is going on -- the file /var/lib/sss/pipes/private/pam is a UNIX socket that processes running with UID=0 talk to when they do a PAM conversation. (non-root processes would go to /var/lib/sss/pipes/pam, the routing is done by the pam_sss.so PAM module). So I guess that vsftp is running as root and doing na PAM conversation here. Jakub, So you suggest to allow this? (In reply to Lukas Vrabec from comment #3) > Jakub, > So you suggest to allow this? What exactly do you propose to allow (what domains should be allowed to touch what types)? I'm not a SELinux expert, I just tried to explain what the SSSD pipes do :) The dac_read_search and dac_override SELinux denials usually appear when there is a UNIX permission problem. Could you provide the output of following command? # ls -l /var/lib/sss/pipes/private /var/lib/sss/pipes [root@rhel7-1 ~]# ls -l /var/lib/sss/pipes/private /var/lib/sss/pipes /var/lib/sss/pipes: total 4 srw-rw-rw-. 1 root root 0 Aug 9 07:09 nss srw-rw-rw-. 1 root root 0 Aug 9 07:09 pac srw-rw-rw-. 1 root root 0 Aug 9 07:09 pam drwx------. 2 sssd sssd 4096 Aug 9 07:09 private srw-rw-rw-. 1 root root 0 Aug 9 07:09 ssh srw-rw-rw-. 1 root root 0 Aug 9 07:09 sudo /var/lib/sss/pipes/private: total 0 srw-------. 1 root root 0 Aug 9 07:09 pam lrwxrwxrwx. 1 root root 50 Aug 9 07:09 sbus-dp_example.com -> /var/lib/sss/pipes/private/sbus-dp_example.com.662 srw-------. 1 root root 0 Jul 28 20:12 sbus-dp_example.com.2447 srw-------. 1 root root 0 Jul 29 14:16 sbus-dp_example.com.3236 srw-------. 1 root root 0 Jul 26 12:59 sbus-dp_example.com.4560 srw-------. 1 root root 0 Aug 1 13:11 sbus-dp_example.com.648 srw-------. 1 root root 0 Jul 27 06:30 sbus-dp_example.com.653 srw-------. 1 root root 0 Aug 4 07:26 sbus-dp_example.com.660 srw-------. 1 root root 0 Aug 9 07:09 sbus-dp_example.com.662 srw-------. 1 root root 0 Aug 3 11:42 sbus-dp_example.com.666 srw-------. 1 root root 0 Aug 5 08:23 sbus-dp_example.com.669 srw-------. 1 root root 0 Aug 9 07:09 sbus-monitor And in case you want this as well: [root@rhel7-1 ~]# ls -ldZ /var/lib/sss/pipes/private /var/lib/sss/pipes drwxr-xr-x. sssd sssd system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes drwx------. sssd sssd system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes/private [root@rhel7-1 ~]# ls -lZ /var/lib/sss/pipes/private /var/lib/sss/pipes /var/lib/sss/pipes: srw-rw-rw-. root root system_u:object_r:sssd_var_lib_t:s0 nss srw-rw-rw-. root root system_u:object_r:sssd_var_lib_t:s0 pac srw-rw-rw-. root root system_u:object_r:sssd_var_lib_t:s0 pam drwx------. sssd sssd system_u:object_r:sssd_var_lib_t:s0 private srw-rw-rw-. root root system_u:object_r:sssd_var_lib_t:s0 ssh srw-rw-rw-. root root system_u:object_r:sssd_var_lib_t:s0 sudo /var/lib/sss/pipes/private: srw-------. root root system_u:object_r:sssd_var_lib_t:s0 pam lrwxrwxrwx. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com -> /var/lib/sss/pipes/private/sbus-dp_example.com.662 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.2447 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.3236 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.4560 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.648 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.653 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.660 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.662 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.666 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-dp_example.com.669 srw-------. root root system_u:object_r:sssd_var_lib_t:s0 sbus-monitor I believe issue is in /var/lib/sss/pipes. Please look on second part of this blog: http://danwalsh.livejournal.com/34903.html This issue should be fixed on sssd side. Do I understand it correctly that owner of the directory /var/lib/sss/pipes/ should be root and not sssd. Scot could you test? (In reply to Lukas Slebodnik from comment #8) > Do I understand it correctly that owner of the directory /var/lib/sss/pipes/ > should be root and not sssd. > > Scot could you test? I read it as the owner of the private pipe sould be root when running as root, but yeah, we need to test this (please note the pipe itself is created when sssd starts, so you'll want to chown the pipe after it's created) (In reply to Jakub Hrozek from comment #9) > (In reply to Lukas Slebodnik from comment #8) > > Do I understand it correctly that owner of the directory /var/lib/sss/pipes/ > > should be root and not sssd. > > > > Scot could you test? > > I read it as the owner of the private pipe sould be root when running as > root, but yeah, we need to test this (please note the pipe itself is created > when sssd starts, so you'll want to chown the pipe after it's created) According to comment 6, owner of the private pam pipe is already root /var/lib/sss/pipes/private: srw-------. root root system_u:object_r:sssd_var_lib_t:s0 pam So the only problem can be with the ownership of directory Jakub, I changed only the owner for both pipes and private, it worked: [root@rhel7-1 ~]# ls -ldZ /var/lib/sss/pipes/private /var/lib/sss/pipes drwxr-xr-x. root sssd system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes drwx------. root sssd system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes/private [root@rhel7-1 ~]# ftp -inv $(hostname) Connected to rhel7-1.example.com (192.168.122.71). 220 (vsFTPd 3.0.2) ftp> user ipauser Secret123 331 Please specify the password. 500 OOPS: cannot change directory:/home/ipauser Login failed. I ran an ausearch and didn't see any new dac_* denials. Anything else I need to do from my side? No, thank you, we just need to figure out what to do with this bug, since we need to support both sssd and root users for sssd. Lukas agreed he would try to fix this by owning the directory by root:sssd Upstream ticket: https://fedorahosted.org/sssd/ticket/3143 * master: f49724cd6b3e0e3274302c3d475e93f7a7094f40 If I'm reading the upstream patch correctly, something isn't working. This is what is expected right? /var/lib/sss/pipes/private should be 750 and sssd:root However, this is what I see: [root@rhel7-0 ~]# rpm -q sssd package sssd is not installed [root@rhel7-0 ~]# yum -y install ipa-server-dns Loaded plugins: product-id, search-disabled-repos, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Resolving Dependencies ... Complete! [root@rhel7-0 ~]# rpm -q sssd sssd-1.14.0-30.el7.x86_64 [root@rhel7-0 ~]# ls -ldZ /var/lib/sss/pipes/private /var/lib/sss/pipes drwxr-xr-x. sssd sssd system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes drwx------. sssd root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes/private That doesn't seem to match what I expect if I'm reading the upstream patch correctly. Am I missing something? (In reply to Scott Poore from comment #19) > Am I missing something? No, you're not missing anything, the specfile backport from upstream to RHEL is wrong. I need to build a new package. Thank you for cathing this, please add FailedQA and I will prepare a new build. Ok, changed. Will test again when fix is available. Thanks (In reply to Scott Poore from comment #21) > Ok, changed. Will test again when fix is available. > > Thanks Scott, can you test sssd-1.14.0-35.el7, please? Looks good. [root@rhel7-4 ~]# rpm -q sssd sssd-1.14.0-35.el7.x86_64 [root@rhel7-4 ~]# ipa-server-install --setup-dns --forwarder=192.168.122.1 --reverse-zone=122.168.192.in-addr.arpa. --allow-zone-overlap -r EXAMPLE.COM -a Secret123 -p Secret123 -U ...trunc... [root@rhel7-4 ~]# kinit admin Password for admin: [root@rhel7-4 ~]# ipa user-add ipauser --first=f --last=l -------------------- Added user "ipauser" -------------------- User login: ipauser First name: f Last name: l Full name: f l Display name: f l Initials: fl Home directory: /home/ipauser GECOS: f l Login shell: /bin/sh Principal name: ipauser Principal alias: ipauser Email address: ipauser UID: 1353400001 GID: 1353400001 Password: False Member of groups: ipausers Kerberos keys available: False [root@rhel7-4 ~]# ipa passwd ipauser New Password: Enter New Password again to verify: ------------------------------------------ Changed password for "ipauser" ------------------------------------------ [root@rhel7-4 ~]# kinit ipauser Password for ipauser: Password expired. You must change it now. Enter new password: Enter it again: [root@rhel7-4 ~]# yum -y install ftp vsftpd; systemctl start vsftpd Loaded plugins: product-id, search-disabled-repos, subscription-manager ...trunc... [root@rhel7-4 ~]# authconfig --enablemkhomedir --update [root@rhel7-4 ~]# su - ipauser Creating home directory for ipauser. -sh-4.2$ exit logout [root@rhel7-4 ~]# ftp -inv $(hostname) Connected to rhel7-4.example.com (192.168.122.74). 220 (vsFTPd 3.0.2) ftp> user ipauser 331 Please specify the password. Password: 230 Login successful. ftp> quit 221 Goodbye. [root@rhel7-4 ~]# ausearch -m avc <no matches> [root@rhel7-4 ~]# ls -ldZ /var/lib/sss/pipes/private /var/lib/sss/pipes drwxr-xr-x. sssd sssd system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes drwxr-x---. sssd root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes/private Thanks, I added the build to the errata tool. Changing state to verified per comment #23 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. https://rhn.redhat.com/errata/RHEA-2016-2476.html |
Description of problem: I'm seeing AVC denials when trying to ftp as an IPA user with vsftpd setup. ---- time->Tue Aug 2 18:52:25 2016 type=PATH msg=audit(1470181945.535:129): item=0 name="/var/lib/sss/pipes/private/pam" objtype=UNKNOWN type=CWD msg=audit(1470181945.535:129): cwd="/" type=SYSCALL msg=audit(1470181945.535:129): arch=c000003e syscall=4 success=no exit=-13 a0=7f3511c17ee0 a1=7ffd35aabb30 a2=7ffd35aabb30 a3=7f3511e192c0 items=1 ppid=1716 pid=2109 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1470181945.535:129): avc: denied { dac_read_search } for pid=2109 comm="vsftpd" capability=2 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tclass=capability type=AVC msg=audit(1470181945.535:129): avc: denied { dac_override } for pid=2109 comm="vsftpd" capability=1 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tclass=capability ---- time->Tue Aug 2 18:52:25 2016 type=PATH msg=audit(1470181945.535:130): item=0 name="/var/lib/sss/pipes/private/pam" objtype=UNKNOWN type=CWD msg=audit(1470181945.535:130): cwd="/" type=SYSCALL msg=audit(1470181945.535:130): arch=c000003e syscall=4 success=no exit=-13 a0=7f3511c17ee0 a1=7ffd35aabb30 a2=7ffd35aabb30 a3=7f3511e192c0 items=1 ppid=1716 pid=2109 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="vsftpd" exe="/usr/sbin/vsftpd" subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1470181945.535:130): avc: denied { dac_read_search } for pid=2109 comm="vsftpd" capability=2 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tclass=capability type=AVC msg=audit(1470181945.535:130): avc: denied { dac_override } for pid=2109 comm="vsftpd" capability=1 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tclass=capability Version-Release number of selected component (if applicable): ipa-server-4.4.0-4.el7.x86_64 sssd-1.14.0-10.el7.x86_64 selinux-policy-3.13.1-91.el7.noarch How reproducible: Steps to Reproduce: 1. ipa-server-install 2. ipa user-add ipauser 3. kinit ipauser # to set password 4. yum -y install ftp vsftpd; systemctl start vsftpd 5. ftp -inv $(hostname) > user ipauser <ipauser password> Actual results: AVC shown above Expected results: I wouldn't expect to see an AVC. Additional info: I'm not sure if this is an selinux-policy bug or something changed within SSSD. So, I'm starting with SSSD. If I add an actual local user, ftp works. Permissions on the file in question: [root@rhel7-1 ~]# ls -lZ /var/lib/sss/pipes/private/pam srw-------. root root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/pipes/private/pam