RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1362716 - selinux avc denial for vsftp login as ipa user
Summary: selinux avc denial for vsftp login as ipa user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukas Slebodnik
QA Contact: Steeve Goveas
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-03 00:09 UTC by Scott Poore
Modified: 2020-05-02 18:27 UTC (History)
14 users (show)

Fixed In Version: sssd-1.14.0-35.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 07:20:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4176 0 None None None 2020-05-02 18:27:26 UTC
Red Hat Product Errata RHEA-2016:2476 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2016-11-03 14:08:11 UTC

Description Scott Poore 2016-08-03 00:09:15 UTC 
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
Comment 2 Jakub Hrozek 2016-08-03 07:27:34 UTC 
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.
Comment 3 Lukas Vrabec 2016-08-08 14:48:33 UTC 
Jakub, 
So you suggest to allow this?
Comment 4 Jakub Hrozek 2016-08-08 16:11:10 UTC 
(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 :)
Comment 5 Milos Malik 2016-08-09 07:15:30 UTC 
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
Comment 6 Scott Poore 2016-08-09 12:13:40 UTC 
[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
Comment 7 Lukas Vrabec 2016-08-09 14:48:50 UTC 
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.
Comment 8 Lukas Slebodnik 2016-08-10 10:12:03 UTC 
Do I understand it correctly that owner of the directory /var/lib/sss/pipes/
should be root and not sssd.

Scot could you test?
Comment 9 Jakub Hrozek 2016-08-10 10:23:05 UTC 
(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)
Comment 10 Lukas Slebodnik 2016-08-10 11:13:23 UTC 
(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
Comment 11 Scott Poore 2016-08-10 14:30:05 UTC 
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?
Comment 12 Jakub Hrozek 2016-08-10 15:49:32 UTC 
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.
Comment 13 Jakub Hrozek 2016-08-12 07:35:39 UTC 
Lukas agreed he would try to fix this by owning the directory by root:sssd
Comment 14 Lukas Slebodnik 2016-08-19 10:26:25 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/3143
Comment 16 Jakub Hrozek 2016-08-26 13:49:02 UTC 
* master: f49724cd6b3e0e3274302c3d475e93f7a7094f40
Comment 19 Scott Poore 2016-09-01 23:08:19 UTC 
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?
Comment 20 Jakub Hrozek 2016-09-02 07:26:50 UTC 
(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.
Comment 21 Scott Poore 2016-09-02 15:54:13 UTC 
Ok, changed.  Will test again when fix is available.

Thanks
Comment 22 Jakub Hrozek 2016-09-05 15:57:09 UTC 
(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?
Comment 23 Scott Poore 2016-09-06 12:55:43 UTC 
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
Comment 24 Jakub Hrozek 2016-09-07 15:41:28 UTC 
Thanks, I added the build to the errata tool.
Comment 26 Scott Poore 2016-09-08 13:01:52 UTC 
Changing state to verified per comment #23
Comment 28 errata-xmlrpc 2016-11-04 07:20:05 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.