Bug 671584

What platform?
rpm -qi 389-ds-base
rpm -qi selinux-policy

~]# rpm -qi 389-ds-base
Name        : 389-ds-base                  Relocations: (not relocatable)
Version     : 1.2.7.5                           Vendor: Fedora Project
Release     : 1.fc14                        Build Date: Thu 16 Dec 2010 11:23:44 AM CST
Install Date: Fri 17 Dec 2010 03:13:33 PM CST      Build Host: x86-10.phx2.fedoraproject.org
Group       : System Environment/Daemons    Source RPM: 389-ds-base-1.2.7.5-1.fc14.src.rpm
Size        : 5756817                          License: GPLv2 with exceptions
Signature   : RSA/SHA256, Thu 16 Dec 2010 09:19:45 PM CST, Key ID 421caddb97a1071f
Packager    : Fedora Project
URL         : http://port389.org/
Summary     : 389 Directory Server (base)
Description :
389 Directory Server is an LDAPv3 compliant server.  The base package includes
the LDAP server and command line utilities for server administration.


~]# rpm -qi selinux-policy
Name        : selinux-policy               Relocations: (not relocatable)
Version     : 3.9.7                             Vendor: Fedora Project
Release     : 20.fc14                       Build Date: Tue 04 Jan 2011 10:28:31 AM CST
Install Date: Mon 17 Jan 2011 09:40:37 PM CST      Build Host: x86-17.phx2.fedoraproject.org
Group       : System Environment/Base       Source RPM: selinux-policy-3.9.7-20.fc14.src.rpm
Size        : 7981448                          License: GPLv2+
Signature   : RSA/SHA256, Wed 05 Jan 2011 11:16:11 AM CST, Key ID 421caddb97a1071f
Packager    : Fedora Project
URL         : http://oss.tresys.com/repos/refpolicy/
Summary     : SELinux policy configuration
Description :
SELinux Reference Policy - modular.
Based off of reference policy: Checked out revision  2.20091117

I believe that the kerberos libraries that are used by ns-slapd require this access.  I believe that this is a duplicate of bug 669385, which is fixed in selinux-policy-3.9.7-25.  Could you test with this newer selinux-policy package to confirm that it is fixed?

(In reply to comment #3)
> I believe that the kerberos libraries that are used by ns-slapd require this
> access.  I believe that this is a duplicate of bug 669385, which is fixed in
> selinux-policy-3.9.7-25.  Could you test with this newer selinux-policy package
> to confirm that it is fixed?

I confirm that the originally reported AVCs are fixed with 3.9.7-25, however, I now see the following AVCs at startup or restart even after a fresh relable & reboot:

type=AVC msg=audit(1296239122.428:4): avc:  denied  { open } for  pid=1281 comm="start-ds-admin" name="console" dev=devtmpfs ino=4063 scontext=system_u:system_r:dirsrvadmin_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file

type=SYSCALL msg=audit(1296239122.428:4): arch=c000003e syscall=2 success=yes exit=3 a0=bd7010 a1=802 a2=7fff3be43bf0 a3=1000 items=0 ppid=1260 pid=1281 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="start-ds-admin" exe="/bin/bash" subj=system_u:system_r:dirsrvadmin_t:s0 key=(null)

type=AVC msg=audit(1296239122.441:5): avc:  denied  { sys_resource } for  pid=1281 comm="start-ds-admin" capability=24  scontext=system_u:system_r:dirsrvadmin_t:s0 tcontext=system_u:system_r:dirsrvadmin_t:s0 tclass=capability

type=AVC msg=audit(1296239122.441:5): avc:  denied  { setrlimit } for  pid=1281 comm="start-ds-admin" scontext=system_u:system_r:dirsrvadmin_t:s0 tcontext=system_u:system_r:dirsrvadmin_t:s0 tclass=process

type=SYSCALL msg=audit(1296239122.441:5): arch=c000003e syscall=160 success=yes exit=0 a0=7 a1=7fff3be43610 a2=0 a3=100 items=0 ppid=1260 pid=1281 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="start-ds-admin" exe="/bin/bash" subj=system_u:system_r:dirsrvadmin_t:s0 key=(null)

type=AVC msg=audit(1296239124.427:6): avc:  denied  { write } for  pid=1368 comm="ldap-agent-bin" name="dirsrv" dev=md0 ino=57514 scontext=system_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir

type=SYSCALL msg=audit(1296239124.427:6): arch=c000003e syscall=21 success=yes exit=0 a0=9182c0 a1=2 a2=7fffd36d16d0 a3=7fffd36d1440 items=0 ppid=1367 pid=1368 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=system_u:system_r:dirsrv_snmp_t:s0 key=(null)

Are these the AVCs that you see in permissive mode during a restart, or is this in enforcing mode?  I want to be sure we deal with them all, so I'd like to see all related AVCs that occur when restarting dirsrv-admin in permissive mode if there is anything else not reported in this bug.

For the admin server restart issues, I believe we need to add:

term_use_console(dirsrvadmin_t)
allow dirsrvadmin_t self:capability { sys_resource };
allow dirsrvadmin_t self:process { setrlimit };

The issue with ldap-agent seems like it may be unable to create a new log file in /var/log/dirsrv, which is labelled as var_log_t.  Do you get the ldap-agent related AVC when starting ldap-agent when it's logfile already exists?

I am able to reproduce the ldap-agent related AVC when starting the dirsrv-snmp service for the first time.  If I put selinux in permissive mode, there are a number of AVCs reported:

type=AVC msg=audit(1296667386.988:174): avc:  denied  { write } for  pid=19549 comm="ldap-agent-bin" name="dirsrv" dev=dm-0 ino=2899995 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=dir
type=SYSCALL msg=audit(1296667386.988:174): arch=c000003e syscall=21 success=yes exit=0 a0=1d182c0 a1=2 a2=7fffa5f71ec0 a3=7fffa5f71c10 items=0 ppid=19548 pid=19549 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=1 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=unconfined_u:system_r:dirsrv_snmp_t:s0 key=(null)
type=AVC msg=audit(1296667386.988:175): avc:  denied  { add_name } for  pid=19549 comm="ldap-agent-bin" name="ldap-agent.log" scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=dir
type=AVC msg=audit(1296667386.988:175): avc:  denied  { create } for  pid=19549 comm="ldap-agent-bin" name="ldap-agent.log" scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_log_t:s0 tclass=file
type=SYSCALL msg=audit(1296667386.988:175): arch=c000003e syscall=2 success=yes exit=3 a0=1d1a060 a1=441 a2=1b6 a3=0 items=0 ppid=19548 pid=19549 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=1 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=unconfined_u:system_r:dirsrv_snmp_t:s0 key=(null)
type=AVC msg=audit(1296667387.016:176): avc:  denied  { write } for  pid=19553 comm="ldap-agent-bin" name="lib" dev=dm-0 ino=2883586 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir
type=AVC msg=audit(1296667387.016:176): avc:  denied  { add_name } for  pid=19553 comm="ldap-agent-bin" name="net-snmp" scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir
type=AVC msg=audit(1296667387.016:176): avc:  denied  { create } for  pid=19553 comm="ldap-agent-bin" name="net-snmp" scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1296667387.016:176): arch=c000003e syscall=83 success=yes exit=0 a0=7fffa5f70b30 a1=1c0 a2=ffffffffffffff80 a3=7fffa5f70800 items=0 ppid=1 pid=19553 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=unconfined_u:system_r:dirsrv_snmp_t:s0 key=(null)
type=AVC msg=audit(1296667387.018:177): avc:  denied  { write } for  pid=19553 comm="ldap-agent-bin" name="net-snmp" dev=dm-0 ino=2900063 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir
type=AVC msg=audit(1296667387.018:177): avc:  denied  { add_name } for  pid=19553 comm="ldap-agent-bin" name="mib_indexes" scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1296667387.018:177): arch=c000003e syscall=83 success=yes exit=0 a0=7fffa5f70b30 a1=1c0 a2=ffffffffffffff80 a3=7fffa5f70800 items=0 ppid=1 pid=19553 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=unconfined_u:system_r:dirsrv_snmp_t:s0 key=(null)
type=AVC msg=audit(1296667387.018:178): avc:  denied  { create } for  pid=19553 comm="ldap-agent-bin" name="0" scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
type=AVC msg=audit(1296667387.018:178): avc:  denied  { write open } for  pid=19553 comm="ldap-agent-bin" name="0" dev=dm-0 ino=2898623 scontext=unconfined_u:system_r:dirsrv_snmp_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
type=SYSCALL msg=audit(1296667387.018:178): arch=c000003e syscall=2 success=yes exit=9 a0=7fffa5f718e0 a1=241 a2=1b6 a3=0 items=0 ppid=1 pid=19553 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="ldap-agent-bin" exe="/usr/sbin/ldap-agent-bin" subj=unconfined_u:system_r:dirsrv_snmp_t:s0 key=(null)

Running audit2allow gives me the following rules for dirsrv_snmp_t:

#============= dirsrv_snmp_t ==============
allow dirsrv_snmp_t var_lib_t:dir { write create add_name };
#!!!! The source type 'dirsrv_snmp_t' can write to a 'file' of the following types:
# dirsrv_snmp_var_run_t, dirsrv_snmp_var_log_t, root_t

allow dirsrv_snmp_t var_lib_t:file { write create open getattr };
#!!!! The source type 'dirsrv_snmp_t' can write to a 'dir' of the following types:
# dirsrv_var_log_t, dirsrv_snmp_var_run_t, var_run_t, root_t

allow dirsrv_snmp_t var_log_t:dir { write add_name };
allow dirsrv_snmp_t var_log_t:file create;
#=========================================

The /var/lib access is something that the Net-SNMP libraries that are used by ldap-agent-bin must be doing.  The /var/log access is ldap-agent-bin trying to create it's log file /var/log/dirsrv/ldap-agent.log.  The odd thing is that this file is created with a context of var_log_t, but the intent is for it to be labelled as dirsrv_snmp_var_log_t.  The dirsrv_snmp_t policy should have this in it already:

type dirsrv_snmp_var_log_t;
logging_log_file(dirsrv_snmp_var_log_t)
manage_files_pattern(dirsrv_snmp_t, dirsrv_var_log_t, dirsrv_snmp_var_log_t);
filetrans_pattern(dirsrv_snmp_t, dirsrv_var_log_t, dirsrv_snmp_var_log_t, file)

Is the problem here that the parent directory that contains the logfile (/var/log/dirsrv) is labelled as var_log_t, which doesn't match what the above filetrans expects?  The initial dirsrv policy had the following in it's .fc file:

var/log/dirsrv              gen_context(system_u:object_r:dirsrv_var_log_t,s0)

It appears that this did not make it through when the policy was moved out of the 389-ds-base package and into selinux-policy-targetted.

Looks like /var/log/dirsrv has the wrong label on it.

F14 policy has

/var/log/dirsrv(/.*)	gen_context(system_u:object_r:dirsrv_var_log_t,s0)


Run restorecon -R -v /var/log/dirsrv 
To fix the label, Did you destroy and recreate this directory by hand?

Whatever /var/lib directory you are using is also mislabeled.

(In reply to comment #8)
> Looks like /var/log/dirsrv has the wrong label on it.
> 
> F14 policy has
> 
> /var/log/dirsrv(/.*) gen_context(system_u:object_r:dirsrv_var_log_t,s0)
> 
> 
> Run restorecon -R -v /var/log/dirsrv 
> To fix the label, Did you destroy and recreate this directory by hand?

The odd thing is that I tried this, and it does not get relabelled:

[root@localhost dirsrv]# ls -lZ /var/log | grep dirsrv
drwxrwx---. nobody  nobody  unconfined_u:object_r:var_log_t:s0 dirsrv
[root@localhost dirsrv]# restorecon -R -v /var/log
[root@localhost dirsrv]# ls -lZ /var/log | grep dirsrv
drwxrwx---. nobody  nobody  unconfined_u:object_r:var_log_t:s0 dirsrv

[root@localhost dirsrv]# semanage fcontext -l | grep dirsrv
...
/var/log/dirsrv(/.*)                               all files          system_u:object_r:dirsrv_var_log_t:s0
...

> 
> Whatever /var/lib directory you are using is also mislabeled.

The Net-SNMP libraries try to create /var/lib/net-snmp the first time that we start ldap-agent.  This directory gets created with a context of var_lib_t by ldap-agent if it doesn't already exist.  Now the odd thing is that starting snmpd will create this directory as well, but it gets created with a context of snmpd_var_lib_t in that case.  Here's what semanage shows for the fcontext for this:

/var/lib/net-snmp(/.*)?                            all files          system_u:object_r:snmpd_var_lib_t:s0

In this case, a restorecon does fix the context of /var/lib/net-snmp.  The problem is that we can't guarantee that snmpd was started on a system where ldap-agent is being started.  Is the right thing to do here to add a transition so ldap-agent will create /var/lib/net-snmp with a context of snmpd_var_lib_t?

That is because

/var/log/dirsrv(/.*)                               all files         
system_u:object_r:dirsrv_var_log_t:s0

should be

/var/log/dirsrv(/.*)?                               all files         
system_u:object_r:dirsrv_var_log_t:s0

Yes if you create the directory it should transiiton.

Miroslav you need to back port the dirsrv policy and the snmp.if from Rawhide to F13/F14.

*** Bug 639524 has been marked as a duplicate of this bug. ***

Fixed in selinux-policy-3.9.7-29.fc14

selinux-policy-3.9.7-29.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-29.fc14

I tested the new package on Fedora 14 and I no longer see the AVCs originally reported.  I do however see this AVC when restarting the dirsrv-admin service:

type=AVC msg=audit(1296844128.917:129): avc:  denied  { search } for  pid=17132 comm="httpd.worker" name="dirsrv" dev=dm-0 ino=2506754 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:dirsrv_config_t:s0 tclass=dir

The initial dirsrv and dirsrv-admin policy had the following macro call in the dirsrv-admin policy (inside of the dirsrvadmin_extend_httpd macro):

==============================
dirsrv_manage_config(httpd_t)
==============================

This macro had these rules:

===============================================
allow $1 dirsrv_config_t:dir manage_dir_perms;
allow $1 dirsrv_config_t:file manage_file_perms;
===============================================

This allowed httpd_t to "search" a dirsrv_config_t directory.  I do not see this in the current selinux-policy source for Fedora 14.  Is there some reason that this part of the policy was not added when we initially moved the policy from 389-ds-base and 389-ds-admin into selinux-policy?

Comparing the original dirsrv-admin policy to the selinux-policy-3.9.7-29 source, I see a few differences.  In the original dirsrvadmin_extend_httpd macro, we had this:

===================================
dirsrv_manage_config(httpd_t)
dirsrv_manage_log(httpd_t)
dirsrv_manage_var_run(httpd_t)
dirsrv_read_share(httpd_t)
dirsrv_signal(httpd_t)
dirsrv_signull(httpd_t)
dirsrvadmin_manage_config(httpd_t)
dirsrvadmin_manage_tmp(httpd_t)
===================================

In the current selinux-policy source, I see this:

=======================================
optional_policy(`
    dirsrvadmin_read_config(httpd_t)
    dirsrv_manage_log(httpd_t)
    dirsrv_manage_var_run(httpd_t)
    dirsrv_read_share(httpd_t)
    dirsrv_signal(httpd_t)
    dirsrv_signull(httpd_t)
    dirsrvadmin_manage_config(httpd_t)
    dirsrvadmin_manage_tmp(httpd_t)
')
=======================================

The big difference here are that dirsrv_manage_config(httpd_t) has been omitted.  I think that dirsrvadmin_read_config(httpd_t) was something that was added later for a different issue.  To fix this, we need dirsrv_manage_config(httpd_t) added to the current policy.

selinux-policy-3.9.7-29.fc14 has been pushed to the Fedora 14 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: https://admin.fedoraproject.org/updates/selinux-policy-3.9.7-29.fc14

You are right,

dirsrv_manage_config(httpd_t)

is missing in F14. I am fixing it. Thank you.

selinux-policy-3.9.7-29.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #18)
> You are right,
> 
> dirsrv_manage_config(httpd_t)
> 
> is missing in F14. I am fixing it. Thank you.

When is a new build planned to fix this?

Building.