Hide Forgot
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.
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
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.
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.
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
Created attachment 387152 [details] Files relates to 389 Directory Server x86_64
Created attachment 387153 [details] Files related to 389 Directory Server i686
(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
Created attachment 387172 [details] Miroslav add this patch for labeling to directory server
Fixed in selinux-policy-3.6.32-79.fc12
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
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
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)
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)
[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.
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.
Ok, I apologize. I was missing /usr/sbin/ns-slapd labeling. Fixed in selinux-policy-3.6.32-86.fc12
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.
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
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?
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.
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.
Created attachment 394971 [details] ns-slapd errors with selinux-policy-targeted-3.6.32-89.fc12.noarch
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?
(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).
Miroslav, please remove the label. Who should I assign this bug to, to get the 389 policy out.
(In reply to comment #25) > Miroslav, please remove the label. Ok. Fixed in selinux-policy-3.6.32-92.fc12
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
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
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.