Bug 799102 - selinux-policy updates break ldapi samba connection to 389ds (IPA)
selinux-policy updates break ldapi samba connection to 389ds (IPA)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: selinux-policy (Show other bugs)
6.2
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Miroslav Grepl
Milos Malik
: TestBlocker
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-01 14:10 EST by Ryan Thomson
Modified: 2012-06-20 08:31 EDT (History)
6 users (show)

See Also:
Fixed In Version: selinux-policy-3.7.19-145.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 08:31:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs showing updates followed by AVC denial and samba failure to connect to slapd via ldapi (4.51 KB, text/plain)
2012-03-01 14:10 EST, Ryan Thomson
no flags Details

  None (edit)
Description Ryan Thomson 2012-03-01 14:10:33 EST
Created attachment 566920 [details]
Logs showing updates followed by AVC denial and samba failure to connect to slapd via ldapi

Description of problem:
After an selinux-policy update, samba can no longer connect to dirsrv/slapd (389ds) via ldapi due to AVC denial. Also, dirsrv fails to restart properly due to AVC denial after the same selinux-policy update.

Version-Release number of selected component (if applicable):
ipa-server-2.1.3-9
389-ds-base-1.2.9.14-1
samba-3.5.10-114
selinux-policy-3.7.19-126.el6_2.9

How reproducible:
Has happened twice after updates to selinux-policy. It presumably occurs every time there is an selinux-policy update or the package is re-installed.

Steps to Reproduce:
1. Update selinux-policy
2. Watch samba connection to dirsrv via ldapi fail
  
Actual results:
Samba connection to slapd via ldapi socket is denied and samba loses ability to talk to LDAP.

Expected results:
Samba connection to slapd remains functional.

Additional info:

I can recover by removing/moving the existing socket (/var/run/slapd-EXAMPLE-COM.socket), restarting "dirsrv" and restarting "smb". This presumably allows "dirsrv" to recreate the socket file with the correct selinux context.

smbd AVC denial shortly after the update:

Feb 28 08:10:27 hostname kernel: type=1400 audit(1330445427.461:27627): avc:  denied  { write } for  pid=22683 comm="smbd" name="slapd-EXAMPLE-COM.socket" dev=dm-0 ino=1308217 scontext=unconfined_u:system_r:smbd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file

samba connection to slapd via ldapi failure:

Feb 28 08:10:27 hostname smbd[22683]: [2012/02/28 08:10:27.472196,  0] lib/smbldap.c:1151(smbldap_connect_system)
Feb 28 08:10:27 hostname smbd[22683]:   failed to bind to server ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket with dn="cn=Directory Manager" Error: Can't contact LDAP server
Feb 28 08:10:27 hostname smbd[22683]:   #011(unknown)

slapd AVC denial when trying to restart "dirsrv" service after selinux-policy update:

Mar  1 09:09:07 hostname kernel: type=1400 audit(1330621747.352:42410): avc:  denied  { unlink } for  pid=7034 comm="ns-slapd" name="slapd-EXAMPLE-COM.socket" dev=dm-0 ino=1308217 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file

Error message on console when trying to restart "dirsrv" service after selinux-policy update:

[01/Mar/2012:09:09:07 -0800] createprlistensockets - PR_Bind() on localhost file /var/run/slapd-EXAMPLE-COM.socket failed: Netscape Portable Runtime error -5982 (Local Network address is in use.)
Comment 2 Daniel Walsh 2012-03-01 16:17:20 EST
This looks like whoever created the sock_file, created it with the wrong context were you running ldap as unconfined_t rather then from the service script?
Comment 3 Ryan Thomson 2012-03-01 16:27:56 EST
I was running ldap (dirsrv/389ds) from the IPA service script (from ipa-server).

The friendly people in #freeipa on FreeNode had this to say about this bz:

<nkinder> richm: I thought the ldapi file was supposed to be labeled as dirsrv_var_run_t
* SEJeff|away is now known as SEJeff
<richm> nkinder: yeah - weird
<nkinder> richm: AVC shows it's just plain var_run_t, so we're not allowed to unlink it.
<nkinder> richm, rthomson: I bet it was a blanked relabel that changed the ldapi socket from dirsrv_var_run_t to var_run_t when selinux-policy was upgraded
<rthomson> nkinder: thanks for the analysis
<nkinder> actually, it looks like it should be slapd_var_run_t
<nkinder> rthomson: what does "ls -lZ" show for the socket file now?
<rthomson> unconfined_u:object_r:dirsrv_var_run_t:s0
<nkinder> rthomson: ok, so it got mislabeled somehow to var_run_t
<nkinder> rthomson: RHEL6, right?
<rthomson> yes
<richm> nkinder: removing the file and letting the directory server recreate it will make sure it is created as dirsrv_var_run_t?
<nkinder> rthomson: looks like a bug in selinux-policy that was fixed in fedora at some time
<nkinder> richm: yes
<nkinder> richm: the problem is that "semanage fcontext -l" on RHEL6 shows that there is no fcontext rule to label /var/run/slapd.* as anything
<nkinder> richm: this means restorecon will change the ldapi socket to the default for the directory, which is var_run_t
<rthomson> You guys rock!
<nkinder> richm: on F16, I see that there is a fcontext rule for /var/run/slapd.*
<richm> ok - so yeah, they must have missed backporting that from fedora to rhel
<nkinder> richm: yep
<nkinder> so restorecon from the selinux-policy upgrade nuked our label, and ns-slapd wasn't allowed to do anything with it anymore
<nkinder> we use a transition when we create the file, so ns-slapd will create it with the proper context if it doesn't already exist
Comment 4 Daniel Walsh 2012-03-01 17:20:45 EST
Looks like we have it commented out on RHEL6 and on in Fedora.


#/var/run/slapd.*	-s	gen_context(system_u:object_r:slapd_var_run_t,s0)
versus

+/var/run/slapd.*	-s	gen_context(system_u:object_r:slapd_var_run_t,s0)
Comment 5 Miroslav Grepl 2012-03-02 03:06:42 EST
I see in RHEL6

#/var/run/slapd.*   -s  gen_context(system_u:object_r:slapd_var_run_t,s0)

I guess there was a reason for this.

AFAIK we wanted to have it with dirsrv_var_run_t. 

Will we need to change it back to slapd_var_run_t?
Comment 6 Nathan Kinder 2012-03-14 19:09:15 EDT
I am not sure why it is commented out in RHEL6.  As far as the dirsrv vs slapd label, I'm not really sure.  I believe the policy I originally wrote used the dirsrv_var_run_t label (before putting it in selinux-policy package).  I'm guessing the slapd_var_run_t label already existed for OpenLDAP, so it was reused.  As long as we have rules like the following for the label you use, it shouldn't matter which label it is:

-------------------------------------------------------------------------
# pid files
manage_files_pattern(dirsrv_t, dirsrv_var_run_t, dirsrv_var_run_t)
files_pid_filetrans(dirsrv_t, dirsrv_var_run_t, { file sock_file })

# ldapi socket
manage_sock_files_pattern(dirsrv_t, dirsrv_var_run_t, dirsrv_var_run_t)
-------------------------------------------------------------------------

I think it should be fine to just do the same thing you are doing in Fedora.
Comment 7 Nathan Kinder 2012-03-14 19:13:33 EDT
One other thought around why the slapd_var_run_t label was used is that other policies might have rules that allow confined processes to connect to a slapd_var_run_t sock_file by using the ldap_stream_connect() macro.  This macro does not use grant any access to a dirsrv_var_run_t sock_file.
Comment 8 Daniel Walsh 2012-03-15 10:12:43 EDT
Yes ldap_stream_connect should probably be adjusted to allow you to connect to dirsrv.
Comment 13 Miroslav Grepl 2012-03-20 16:09:00 EDT
Fixed in selinux-policy-3.7.19-142.el6
Comment 14 Nathan Kinder 2012-03-22 15:57:29 EDT
It looks as if the fcontext rule was added to label the socket file as slapd_var_run_t, but no rule was updated to allow dirsrv_t to manage a sock_file with that label.  Scott will add the AVC and semanage output from his test system.
Comment 15 Nathan Kinder 2012-03-22 15:58:38 EDT
Here are details from Scott's testing:

# rpm -q selinux-policy
selinux-policy-3.7.19-142.el6.noarch

# ipactl restart
Restarting Directory Service
Shutting down dirsrv: 
    PKI-IPA...[  OK  ]
    TESTRELM-COM...[  OK  ]
Starting dirsrv: 
    PKI-IPA...[  OK  ]
    TESTRELM-COM...[21/Mar/2012:15:32:03 -0400] createprlistensockets -
PR_Bind() on localhost file /var/run/slapd-TESTRELM-COM.socket failed: Netscape
Portable Runtime error -5982 (Local Network address is in use.)
[FAILED]
  *** Warning: 1 instance(s) failed to start
Failed to read data from Directory Service: Failed to get list of services to
probe status:
Directory Server is stopped
Shutting down
Shutting down dirsrv: 
    PKI-IPA...[  OK  ]
    TESTRELM-COM... server already stopped[FAILED]
  *** Error: 1 instance(s) unsuccessfully stopped[FAILED]

# ausearch -m AVC
----
time->Wed Mar 21 15:32:03 2012
type=SYSCALL msg=audit(1332358323.624:202): arch=c000003e syscall=87 success=no
exit=-13 a0=f68fd2 a1=f682f2 a2=45 a3=6b636f732e4d4f43 items=0 ppid=14688
pid=14689 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts0 ses=10 comm="ns-slapd" exe="/usr/sbin/ns-slapd"
subj=unconfined_u:system_r:dirsrv_t:s0 key=(null)
type=AVC msg=audit(1332358323.624:202): avc:  denied  { unlink } for  pid=14689
comm="ns-slapd" name="slapd-TESTRELM-COM.socket" dev=dm-0 ino=1966792
scontext=unconfined_u:system_r:dirsrv_t:s0
tcontext=unconfined_u:object_r:slapd_var_run_t:s0 tclass=sock_file

# semanage fcontext -l | grep /var/run/slapd
/var/run/slapd.*                                   socket            
system_u:object_r:slapd_var_run_t:s0 
/var/run/slapd\.args                               regular file      
system_u:object_r:slapd_var_run_t:s0 
/var/run/slapd\.pid                                regular file      
system_u:object_r:slapd_var_run_t:s0
Comment 16 Nathan Kinder 2012-03-22 16:29:49 EDT
I just looked at the source for selinux-policy-3.7.19-142.el6, and I think a few changes are needed if you are going to use slapd_var_run_t for /var/run/slapd.* socket files. The dirsrv policy currently expects the socket file to be dirsrv_var_run_t (and I believe it will still create it that way at runtime due to it's transition rule).

Here is what I think it needed if you want to use slapd_var_run_t:

-----------------------------------------------------------------------
dirsrv local policy needs to add:
manage_sock_files_pattern(dirsrv_t, slapd_var_run_t, slapd_var_run_t)

dirsrv_manage_var_run() - needs to add:
allow $1 slapd_var_run_t:sock_file manage_file_perms;

dirsrv_stream_connect() - needs to add:
stream_connect_pattern($1, slapd_var_run_t, slapd_var_run_t, dirsrv_t)

ldap_stream_connect_dirsrv() - needs to add:
stream_connect_pattern($1, slapd_var_run_t, slapd_var_run_t, dirsrv_t)

-----------------------------------------------------------------------

Please note that a dirsrv_t process will still create /var/run/slapd.* files with a dirsrv_t label at runtime due to the transition rule, yet a restorecon will change the label to slapd_var_run_t.  This seems a bit inconsistent, but it should work as long as we are allowed to work with either label.
Comment 17 Miroslav Grepl 2012-03-23 03:54:43 EDT
>Please note that a dirsrv_t process will still create /var/run/slapd.* files
>with a dirsrv_t label at runtime due to the transition rule, yet a restorecon
>will change the label to slapd_var_run_t.  This seems a bit inconsistent, but
>it should work as long as we are allowed to work with either label.

ok and now we know the reason why we had commented 

#/var/run/slapd.*   -s  gen_context(system_u:object_r:slapd_var_run_t,s0)

So you are saying this is not the same as we have in Fedora. Because I made things as we have in Fedora.


dirsrv_stream_connect()
ldap_stream_connect_dirsrv()

are not an issue because these interfaces are always called together.
Comment 18 Nathan Kinder 2012-03-23 11:56:40 EDT
Yes, this is broken in Fedora as well.  I just tested on F16 with selinux-policy-3.10.0-75.fc16.noarch, and the same problem exists.

Starting dirsrv creates the socket file with dirsrv_var_run_t:

-----------------------------------------------------------------------
[root@localhost ~]# systemctl start dirsrv.target
[root@localhost ~]# ps -ef | grep slapd
nobody   22917     1  1 08:50 ?        00:00:00 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -i /var/run/dirsrv/slapd-localhost.pid -w /var/run/dirsrv/slapd-localhost.startpid
root     22958 10724  0 08:50 pts/3    00:00:00 grep --color=auto slapd
[root@localhost ~]# ls -lZ /var/run/slapd-localhost.socket 
srw-rw-rw-. root root system_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-localhost.socket
-----------------------------------------------------------------------

Running restorecon changes the context of the socket file to slapd_var_run_t.  I ran this while ns-slapd was still up and running:

-----------------------------------------------------------------------
[root@localhost ~]# restorecon -v /var/run/slapd-localhost.socket
restorecon reset /run/slapd-localhost.socket context system_u:object_r:dirsrv_var_run_t:s0->system_u:object_r:slapd_var_run_t:s0
[root@localhost ~]# ls -lZ /var/run/slapd-localhost.socket 
srw-rw-rw-. root root system_u:object_r:slapd_var_run_t:s0 /var/run/slapd-localhost.socket
-----------------------------------------------------------------------

At this point, a restart of dirsrv will fail since dirsrv_t is not allowed to unlink the relabelled socket file:


-----------------------------------------------------------------------
[root@localhost ~]# systemctl restart dirsrv.target
[root@localhost ~]# ps -ef | grep slapd
root     22990 10724  0 08:51 pts/3    00:00:00 grep --color=auto slapd

type=AVC msg=audit(1332517857.460:332): avc:  denied  { unlink } for  pid=22980 comm="ns-slapd" name="slapd-localhost.socket" dev=tmpfs ino=506215 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:slapd_var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1332517857.460:332): arch=c000003e syscall=87 success=no exit=-13 a0=be40f2 a1=bf09cf a2=0 a3=b0140c items=0 ppid=1 pid=22980 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0 key=(null)
-----------------------------------------------------------------------
Comment 19 Miroslav Grepl 2012-03-26 08:08:02 EDT
Ok, you want to have dirsrv the socket file with slapd_var_run_t for 

/var/run/slapd.* sockets.

right? 

But we have in the policy

manage_sock_files_pattern(dirsrv_t, dirsrv_var_run_t, dirsrv_var_run_t)
files_pid_filetrans(dirsrv_t, dirsrv_var_run_t, { file dir sock_file })

The problem is these sockets files are created by dirsrv. I would stay with dirsrv_var_run_t and make this working with this label.
Comment 20 Nathan Kinder 2012-03-26 11:01:51 EDT
(In reply to comment #19)
> The problem is these sockets files are created by dirsrv. I would stay with
> dirsrv_var_run_t and make this working with this label.

I am fine with this approach, as it is the least intrusive.
Comment 21 Miroslav Grepl 2012-03-27 13:26:55 EDT
Which means if you stop all services and remove /var/run/slapd* sockets and then start all services everything should work. But just don't run restorecon on /var/run/slapd* sockets. I need to comment it as we had.

And this bug actually is not bug.
Comment 22 Ryan Thomson 2012-03-27 13:44:33 EDT
> Which means if you stop all services and remove /var/run/slapd* sockets and
> then start all services everything should work. But just don't run restorecon
> on /var/run/slapd* sockets. I need to comment it as we had.
> 
> And this bug actually is not bug.

Excuse my lack of understanding but does this mean that nothing is going to change and that every time I update selinux-policy, that Samba will lose it's connection to my LDAP server?
Comment 23 Nathan Kinder 2012-03-27 13:49:02 EDT
(In reply to comment #21)
> Which means if you stop all services and remove /var/run/slapd* sockets and
> then start all services everything should work. But just don't run restorecon
> on /var/run/slapd* sockets. I need to comment it as we had.
> 
> And this bug actually is not bug.

If you simply comment out the rule (like below), won't we still have a problem?

-----------------------------------------------------------------------
#/var/run/slapd.* -s gen_context(system_u:object_r:slapd_var_run_t,s0)
-----------------------------------------------------------------------

In this case, a restorecon will change /var/run/slapd.* socket files to
var_run_t, and ns-slapd (dirsrv_t) will not be allowed to delete it during a
restart.  We can't control when a restorecon will run, so this is a problem. 
Isn't the right approach to add a rule like this:

-----------------------------------------------------------------------
/var/run/slapd.* -s gen_context(system_u:object_r:dirsrv_var_run_t,s0)
-----------------------------------------------------------------------
Comment 24 Miroslav Grepl 2012-03-27 14:16:24 EDT
Nathan,
yes I meant what you wrote

/var/run/slapd.* -s gen_context(system_u:object_r:dirsrv_var_run_t,s0)
Comment 25 Miroslav Grepl 2012-03-28 04:00:34 EDT
I added changes to Fedora, backporting to RHEL6.3.
Comment 26 Scott Poore 2012-04-04 12:49:26 EDT
Do you know yet when that will make it into RHEL?   Or is it included in the 3.7.19-144 rev?
Comment 27 Miroslav Grepl 2012-04-04 12:56:26 EDT
This is going to be in -145.el6 release tomorrow.
Comment 29 Scott Poore 2012-04-09 14:30:07 EDT
If it helps, here's the verification I did around the IPA testing related to this for bug 803054:

# ipactl status
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
DNS Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING

# restorecon /var/run/slapd-TESTRELM-COM.socket

# ls -lZ /var/run/slapd-TESTRELM-COM.socket
srw-rw-rw-. root root unconfined_u:object_r:slapd_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# rm /var/run/slapd-TESTRELM-COM.socket
rm: remove socket `/var/run/slapd-TESTRELM-COM.socket'? y

# ipactl start
Starting Directory Service
Starting dirsrv: 
    PKI-IPA...                                             [  OK  ]
    TESTRELM-COM...                                        [  OK  ]
Starting KDC Service
Starting Kerberos 5 KDC:                                   [  OK  ]
Starting KPASSWD Service
Starting Kerberos 5 Admin Server:                          [  OK  ]
Starting DNS Service
Starting named:                                            [  OK  ]
Starting MEMCACHE Service
Starting ipa_memcached:                                    [  OK  ]
Starting HTTP Service
Starting httpd: [Mon Apr 09 12:46:02 2012] [warn] worker ajp://localhost:9447/ already used by another worker
[Mon Apr 09 12:46:02 2012] [warn] worker ajp://localhost:9447/ already used by another worker
                                                           [  OK  ]
Starting CA Service
Starting pki-ca:                                           [  OK  ]

# ls -lZ /var/run/slapd-TESTRELM-COM.socket
srw-rw-rw-. root root unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# yum update selinux-policy
<snip>
Running Transaction
  Updating   : selinux-policy-3.7.19-145.el6.noarch                                                1/4 
  Updating   : selinux-policy-targeted-3.7.19-145.el6.noarch                                       2/4 
  Cleanup    : selinux-policy-targeted-3.7.19-142.el6.noarch                                       3/4 
  Cleanup    : selinux-policy-3.7.19-142.el6.noarch                                                4/4 
Installed products updated.


Updated:
  selinux-policy.noarch 0:3.7.19-145.el6                                                               

Dependency Updated:
  selinux-policy-targeted.noarch 0:3.7.19-145.el6                                                      

Complete!
</snip>

# ipactl status
Directory Service: RUNNING
KDC Service: RUNNING
KPASSWD Service: RUNNING
DNS Service: RUNNING
MEMCACHE Service: RUNNING
HTTP Service: RUNNING
CA Service: RUNNING
# ls -lZ /var/run/slapd-TESTRELM-COM.socket 
srw-rw-rw-. root root unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# restorecon /var/run/slapd-TESTRELM-COM.socket

# ls -lZ /var/run/slapd-TESTRELM-COM.socket 
srw-rw-rw-. root root unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-TESTRELM-COM.socket

# rpm -q selinux-policy
selinux-policy-3.7.19-145.el6.noarch

# bunzip2 -c /usr/share/selinux/targeted/dirsrv.pp.bz2 | strings | grep /var/run/slapd
/var/run/slapd.* -s system_u:object_r:dirsrv_var_run_t:s0
Comment 31 errata-xmlrpc 2012-06-20 08:31:48 EDT
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-2012-0780.html

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