Bug 559298 - SELinux is preventing /usr/sbin/smbd "connectto" access on /var/run/slapd-*.socket
Summary: SELinux is preventing /usr/sbin/smbd "connectto" access on /var/run/slapd-*.s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-27 17:23 UTC by Anthony Messina
Modified: 2010-03-04 00:17 UTC (History)
4 users (show)

Fixed In Version: selinux-policy-3.6.32-92.fc12
Clone Of:
Environment:
Last Closed: 2010-03-04 00:17:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Files relates to 389 Directory Server x86_64 (40.22 KB, text/plain)
2010-01-27 18:50 UTC, Anthony Messina
no flags Details
Files related to 389 Directory Server i686 (40.00 KB, text/plain)
2010-01-27 18:50 UTC, Anthony Messina
no flags Details
Miroslav add this patch for labeling to directory server (2.52 KB, application/octet-stream)
2010-01-27 20:31 UTC, Daniel Walsh
no flags Details
ns-slapd errors with selinux-policy-targeted-3.6.32-89.fc12.noarch (13.91 KB, text/plain)
2010-02-18 19:36 UTC, Anthony Messina
no flags Details

Description Anthony Messina 2010-01-27 17:23:37 UTC
Using 389 DS LDAPI with SELinux enforcing, Samba is prevented from connecting to the 389 DS socket file at /var/run/slapd-<instance name>.socket

node=barrington.messinet.com type=AVC msg=audit(1264581612.121:2503): avc:  denied  { connectto } for  pid=25078 comm="smbd" path="/var/run/slapd-barrington.socket" scontext=unconfined_u:system_r:smbd_t:s0 tcontext=unconfined_u:system_r:initrc_t:s0 tclass=unix_stream_socket

node=barrington.messinet.com type=SYSCALL msg=audit(1264581612.121:2503): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfc161c0 a2=174624 a3=b76ee038 items=0 ppid=24870 pid=25078 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="smbd" exe="/usr/sbin/smbd" subj=unconfined_u:system_r:smbd_t:s0 key=(null)

I saw that the socket file was using the initrc_t context, which seems to be wrong, so after relabeling, the file is now:

system_u:object_r:var_run_t:s0   slapd-barrington.socket

The strange thing is, even after restarting Samba, I still get the same SELinux denial referring to the initrc_t context even though the socket is labeled with the var_run_t context.

Comment 1 Daniel Walsh 2010-01-27 17:53:20 UTC
The problem is 389 DS LDAPI process is running as initrc_t

ps -eZ | grep initrc_t

You could attempt to label this executable as slapd_exec_t and restart it. 
But you will probably hit other labeling problems.

You could just load a custom policy module using audit2allow -M myldap

Comment 2 Anthony Messina 2010-01-27 18:04:00 UTC
Yep, you're right:

~]# ps -eZ | grep initrc_t
system_u:system_r:initrc_t:s0    1216 ?        00:00:07 ldap-agent-bin
unconfined_u:system_r:initrc_t:s0 27809 ?      00:00:40 ns-slapd

Is this something that should be fixed with the real policy eventually? I guess that would mean that 389 DS would need a policy/context/etc.  That is beyone my skills.

I'll do a custom policy for now. Thanks again.

Comment 3 Daniel Walsh 2010-01-27 18:14:49 UTC
Is 389 shipped as a rpm?  If yes could you give me the rpm -ql of it.  We can probably add it to ldap policy, but need to set the labeling correctly.

Comment 4 Anthony Messina 2010-01-27 18:49:39 UTC
Yes, it is shipped as rpms -- the former [Fedora|RedHat] Directory Server.  It has a bunch of subpackages, etc.  I'll try to get you a list of each, which I'll attach.

~]# rpm -qa|grep 389|sort
389-admin-1.1.10-1.fc12.x86_64
389-admin-console-1.1.4-2.fc12.noarch
389-admin-console-doc-1.1.4-2.fc12.noarch
389-adminutil-1.1.8-4.fc12.x86_64
389-console-1.1.3-5.fc12.noarch
389-ds-1.1.3-5.fc12.noarch
389-ds-base-1.2.5-1.fc12.x86_64
389-ds-console-1.2.0-5.fc12.noarch
389-ds-console-doc-1.2.0-5.fc12.noarch
389-dsgw-1.1.4-1.fc12.x86_64

Comment 5 Anthony Messina 2010-01-27 18:50:19 UTC
Created attachment 387152 [details]
Files relates to 389 Directory Server x86_64

Comment 6 Anthony Messina 2010-01-27 18:50:51 UTC
Created attachment 387153 [details]
Files related to 389 Directory Server i686

Comment 7 Anthony Messina 2010-01-27 18:51:48 UTC
(In reply to comment #3)
> Is 389 shipped as a rpm?  If yes could you give me the rpm -ql of it.  We can
> probably add it to ldap policy, but need to set the labeling correctly.    

The file lists are attached, created with the following command:

for pkg in $(rpm -qa|grep 389|sort); do echo "##### $pkg" >> 389-files.txt & rpm -ql $pkg >> 389-files.txt; done

Comment 8 Daniel Walsh 2010-01-27 20:31:07 UTC
Created attachment 387172 [details]
Miroslav add this patch for labeling to directory server

Comment 9 Miroslav Grepl 2010-01-29 09:18:16 UTC
Fixed in selinux-policy-3.6.32-79.fc12

Comment 10 Fedora Update System 2010-02-03 23:22:15 UTC
selinux-policy-3.6.32-82.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-82.fc12

Comment 11 Fedora Update System 2010-02-05 01:46:46 UTC
selinux-policy-3.6.32-84.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1492

Comment 12 Anthony Messina 2010-02-06 16:55:24 UTC
On a fresh reboot/relabel, the 389 DS is still running in the initrc_t context:

ps -eZ | grep initrc_t
system_u:system_r:initrc_t:s0    1046 ?        00:00:00 ns-slapd
system_u:system_r:initrc_t:s0    1228 ?        00:00:00 ldap-agent-bin

Which gives the socket a label of;
system_u:object_r:var_run_t:s0

The difference now, is that samba seems to connect to the socket, even in enforcing mode -- so samba seems to have access, even though the label is wrong, 389 DS is still running in initrc_t, and I still get a denial.

node=elburn.messinet.com type=AVC msg=audit(1265474710.579:16): avc:  denied  { connectto } for  pid=1691 comm="smbd" path="/var/run/slapd-elburn.socket" scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket

node=elburn.messinet.com type=SYSCALL msg=audit(1265474710.579:16): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd0b250 a2=469624 a3=1b6fdc0 items=0 ppid=1548 pid=1691 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="smbd" exe="/usr/sbin/smbd" subj=system_u:system_r:smbd_t:s0 key=(null)

Comment 13 Daniel Walsh 2010-02-08 19:39:30 UTC
What is the label on ns-slapd?  What is its path?

Should be labeled slapd_exec_t.

/usr/sbin/ns-slapd	--	gen_context(system_u:object_r:slapd_exec_t,s0)

Comment 14 Anthony Messina 2010-02-08 19:59:56 UTC
[root@chicago ~]# ls -lZ /usr/sbin/ns-slapd
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/ns-slapd

[root@chicago ~]# restorecon -Fv /usr/sbin/ns-slapd

[root@chicago ~]# ls -lZ /usr/sbin/ns-slapd
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/ns-slapd

This using:
[root@chicago ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.6.32-82.fc12.noarch

and after a full reboot/relabel since I saw it was fixed in selinux-policy-3.6.32-79.fc12

i haven't seen the -84 release hit the testing repo yet.  i will try with that one as well.

Comment 15 Daniel Walsh 2010-02-08 21:11:55 UTC
Never mind it is not there yet.
Miroslav it does not look like the fix is in F12.

Miroslav can you copy the labeling of ldap.te, ldap.if and ldap.fc from Rawhide into F12.

Comment 16 Miroslav Grepl 2010-02-09 09:50:26 UTC
Ok, I apologize. I was missing /usr/sbin/ns-slapd labeling.

Fixed in selinux-policy-3.6.32-86.fc12

Comment 17 Fedora Update System 2010-02-11 14:39:58 UTC
selinux-policy-3.6.32-84.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Anthony Messina 2010-02-13 03:57:40 UTC
It looks like the 389 DS folks are working on an SELinux policy module.  Will this all work together or will this present conflicts?

http://cvs.fedoraproject.org/viewvc/rpms/389-ds-base/F-12/389-ds-base.spec?view=log

Comment 19 Rich Megginson 2010-02-13 04:01:15 UTC
389-ds-base 1.2.6.a1 and 389-admin 1.1.11.a1, currently in the testing repos, have -selinux sub-packages which should allow selinux to work.  Have you tried those packages?

Comment 20 Anthony Messina 2010-02-13 04:18:54 UTC
I haven't tried them yet.  I just noticed them when I was checking up on this bug (seeing if the -86 release was in updates-testing) when I noticed the 389 DS selinux packages.  I was questioning because I wasn't sure if the fixes that Miroslav was working on would be in conflict with the 389 selinux stuff from Rich, et. al.

Looking at the sources in git (http://git.fedorahosted.org/git/?p=389/ds.git;a=blob;f=selinux/dirsrv.te;h=ddcc2f1e1c8dcfbf25ab609a1ca4387ce0dd1ad1;hb=HEAD)  it appears as though there will be a conflict.  I think Dan Walsh's patch is using the same ldap types, etc. as openldap.

Comment 21 Anthony Messina 2010-02-18 19:36:12 UTC
After upgrading to selinux-policy-targeted-3.6.32-89.fc12.noarch and rebooting with a relabel, many new SELinux errors are reported which block the startup of dirsrv in enforcing mode.

#audit2allow says (which seems way too unrestricted):

#============= slapd_t ==============
allow slapd_t etc_runtime_t:file write;
#!!!! The source type 'slapd_t' can write to a 'dir' of the following types:
# slapd_db_t, var_log_t, slapd_log_t, slapd_var_run_t, var_lock_t, tmp_t, slapd_tmp_t, slapd_replog_t, var_run_t, root_t

allow slapd_t etc_t:dir { write remove_name add_name };
allow slapd_t etc_t:file { write rename create unlink link };
allow slapd_t self:capability { fowner fsetid sys_nice };
allow slapd_t self:process { signull getsched };
#!!!! The source type 'slapd_t' can write to a 'dir' of the following types:
# slapd_db_t, var_log_t, slapd_log_t, slapd_var_run_t, var_lock_t, tmp_t, slapd_tmp_t, slapd_replog_t, var_run_t, root_t

allow slapd_t tmpfs_t:dir { write remove_name add_name };
#!!!! The source type 'slapd_t' can write to a 'file' of the following types:
# slapd_db_t, slapd_lock_t, slapd_log_t, slapd_var_run_t, slapd_tmp_t, slapd_replog_t, root_t

allow slapd_t tmpfs_t:file { write getattr link read create unlink open };
allow slapd_t var_lock_t:dir setattr;

There are so many errors on startup, I'll included the audit stuff in an attachment.

Comment 22 Anthony Messina 2010-02-18 19:36:55 UTC
Created attachment 394971 [details]
ns-slapd errors with selinux-policy-targeted-3.6.32-89.fc12.noarch

Comment 23 Nathan Kinder 2010-02-18 20:00:09 UTC
We really shouldn't be making slapd_t apply to 389.  I wrote a policy module for 389 that has been in the Fedora testing repo for people to try out before we push it into stable.  I would really prefer that we use the 389 specific policy instead of trying to make slapd_t apply to both OpenLDAP and 389 as the products have fairly different requirements in some areas.

Can we get the changes to make ns-slapd use slapd_t backed out, especially since it appears to be breaking peoples installations in enforcing mode?

Comment 24 Anthony Messina 2010-02-18 20:42:45 UTC
(In reply to comment #23)
> We really shouldn't be making slapd_t apply to 389.  I wrote a policy module

I agree with that.  At the time of this initial report and being the reporter, I was not aware of a separately developed selinux module for 389 DS.

On that note, would the right thing be to merge the currently separate 389 DS SELinux bits into the selinux-policy-* package(s) or to maintain that policy module over with the 389 DS folks, where it exists now?

On another note, Nathan, would you recommend upgrading to the alpha version in updates-testing on a non-professional, but still production site?  I use LDAP quite heavily here (messinet.com).

Comment 25 Daniel Walsh 2010-02-18 20:45:30 UTC
Miroslav, please remove the label.

Who should I assign this bug to, to get the 389 policy out.

Comment 26 Miroslav Grepl 2010-02-23 13:49:57 UTC
(In reply to comment #25)
> Miroslav, please remove the label.

Ok.

Fixed in selinux-policy-3.6.32-92.fc12

Comment 27 Fedora Update System 2010-02-23 20:58:28 UTC
selinux-policy-3.6.32-92.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-92.fc12

Comment 28 Fedora Update System 2010-02-26 03:45:18 UTC
selinux-policy-3.6.32-92.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2953

Comment 29 Fedora Update System 2010-03-04 00:13:58 UTC
selinux-policy-3.6.32-92.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.


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