Bug 955703

In Enforcing mode, I see following in /var/log/dirsrv/admin-serv/error:

[Fri Apr 26 15:50:13 2013] [notice] caught SIGTERM, shutting down
[Fri Apr 26 15:50:14 2013] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0
[Fri Apr 26 15:50:15 2013] [notice] Access Host filter is: *.example.com
[Fri Apr 26 15:50:15 2013] [notice] Access Address filter is: *
[Fri Apr 26 15:50:16 2013] [notice] Apache/2.2.15 (Unix) configured -- resuming normal operations
[Fri Apr 26 15:50:16 2013] [notice] Access Host filter is: *.example.com
[Fri Apr 26 15:50:16 2013] [notice] Access Address filter is: *
Permission denied
[Fri Apr 26 15:50:17 2013] [notice] [client 192.168.122.184] admserv_host_ip_check: ap_get_remote_host could not resolve 192.168.122.184

When I switch to permissive mode, "Permission denied" error from log goes away. audit.log with dontaudit rules disabled sent to mmalik.

Ok, it looks like the problem is with the lock file.

allow httpd_dirsrvadmin_script_t var_lock_t:file { getattr unlink };

Do you run restorecon on the lock file in the init script?

As I looked at the audit.log, it seems not to be an issue with var_lock_t. The issue is with these rules (got from audit2allow):

allow httpd_dirsrvadmin_script_t default_context_t:dir search;
allow httpd_dirsrvadmin_script_t default_context_t:file { read getattr open };
allow httpd_dirsrvadmin_script_t file_context_t:dir search;
allow httpd_dirsrvadmin_script_t file_context_t:file { read getattr open };

because dirserver calles restorecon and it keeps httpd_dirsrvadmin_script_t type. That's why the lock file didn't get the correct context in enforcing.

I don't think so. The restorecon should called from init script as we mentioned it in RHEL6.5 bug. These are dontaudit rules and we don't allow them on RHEL6.5 where we got it working.

(In reply to comment #6)
> Ok, it looks like the problem is with the lock file.
> 
> allow httpd_dirsrvadmin_script_t var_lock_t:file { getattr unlink };
> 
> Do you run restorecon on the lock file in the init script?

Yes, restorecon is run on the lock file. I checked and lock file has correct label before and after restart.

[jrusnack@dstet dirsrv]$ ls -Z /var/lock/subsys/dirsrv-admin
-rw-------. root root unconfined_u:object_r:dirsrv_var_lock_t:s0
/var/lock/subsys/dirsrv-admin

Ok, and if you turn on dontaudit rules

# semodule -B

re-test in permissive mode

# setenforce 0
# sesearch -m avc -ts recent

shows anything?

(In reply to comment #10)
> Ok, and if you turn on dontaudit rules
> 
> # semodule -B
> 
> re-test in permissive mode
> 
> # setenforce 0
> # sesearch -m avc -ts recent
> 
> shows anything?

sesearch not found, so I used ausearch:

[jrusnack@dstet ~]$ sudo semodule -B
[jrusnack@dstet ~]$ sudo setenforce 0
re-test
[jrusnack@dstet ~]$ sudo ausearch -m avc -ts recent
----
time->Tue Apr 30 22:33:41 2013
type=SYSCALL msg=audit(1367354021.103:25939): arch=c000003e syscall=2 success=yes exit=5 a0=7f577063c400 a1=0 a2=1b6 a3=0 items=0 ppid=3043 pid=3185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null)
type=AVC msg=audit(1367354021.103:25939): avc:  denied  { open } for  pid=3185 comm="restorecon" name="file_contexts" dev=dm-0 ino=147067 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:file_context_t:s0 tclass=file
type=AVC msg=audit(1367354021.103:25939): avc:  denied  { read } for  pid=3185 comm="restorecon" name="file_contexts" dev=dm-0 ino=147067 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:file_context_t:s0 tclass=file
----
time->Tue Apr 30 22:33:41 2013
type=SYSCALL msg=audit(1367354021.103:25938): arch=c000003e syscall=2 success=no exit=-2 a0=7f577063ca00 a1=0 a2=1b6 a3=0 items=0 ppid=3043 pid=3185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null)
type=AVC msg=audit(1367354021.103:25938): avc:  denied  { search } for  pid=3185 comm="restorecon" name="files" dev=dm-0 ino=131533 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:file_context_t:s0 tclass=dir
type=AVC msg=audit(1367354021.103:25938): avc:  denied  { search } for  pid=3185 comm="restorecon" name="contexts" dev=dm-0 ino=131527 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:default_context_t:s0 tclass=dir
----
time->Tue Apr 30 22:33:41 2013
type=SYSCALL msg=audit(1367354021.103:25940): arch=c000003e syscall=5 success=yes exit=0 a0=5 a1=7fff0a05d2e0 a2=7fff0a05d2e0 a3=7fff0a05cfe0 items=0 ppid=3043 pid=3185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null)
type=AVC msg=audit(1367354021.103:25940): avc:  denied  { getattr } for  pid=3185 comm="restorecon" path="/etc/selinux/targeted/contexts/files/file_contexts" dev=dm-0 ino=147067 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=unconfined_u:object_r:file_context_t:s0 tclass=file
----
time->Tue Apr 30 22:33:41 2013
type=SYSCALL msg=audit(1367354021.198:25941): arch=c000003e syscall=2 success=yes exit=6 a0=7f577063c560 a1=0 a2=1b6 a3=0 items=0 ppid=3043 pid=3185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null)
type=AVC msg=audit(1367354021.198:25941): avc:  denied  { open } for  pid=3185 comm="restorecon" name="customizable_types" dev=dm-0 ino=131888 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:default_context_t:s0 tclass=file
type=AVC msg=audit(1367354021.198:25941): avc:  denied  { read } for  pid=3185 comm="restorecon" name="customizable_types" dev=dm-0 ino=131888 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:default_context_t:s0 tclass=file
----
time->Tue Apr 30 22:33:41 2013
type=SYSCALL msg=audit(1367354021.198:25942): arch=c000003e syscall=5 success=yes exit=0 a0=6 a1=7fff0a05dfb0 a2=7fff0a05dfb0 a3=7fff0a05dea0 items=0 ppid=3043 pid=3185 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="restorecon" exe="/sbin/setfiles" subj=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 key=(null)
type=AVC msg=audit(1367354021.198:25942): avc:  denied  { getattr } for  pid=3185 comm="restorecon" path="/etc/selinux/targeted/contexts/customizable_types" dev=dm-0 ino=131888 scontext=unconfined_u:system_r:httpd_dirsrvadmin_script_t:s0 tcontext=system_u:object_r:default_context_t:s0 tclass=file

Ok, it looks it is executed by different way against RHEL6.5 where we have this working without these rules.

Is it working with a local policy with these rules?

When I build local policy with those rules:

[jrusnack@dstet ~]$ audit2allow -M adminpol -R < avc 
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i adminpol.pp

[jrusnack@dstet ~]$ sudo semodule -i adminpol.pp 
re-test
[jrusnack@dstet ~]$ sudo ausearch -m avc -ts recent
<no matches>

When I set enforcing mode, admin log does NOT contain Permission denied as it did. So, with local policy this works.

Where is the restorecon called exactly?

In /etc/init.d/dirsrv-admin script:

[jrusnack@dstet ~]$ cat /etc/init.d/dirsrv-admin | grep -n -C 5 restorecon
163-            RETVAL=1
164-        fi
165-    fi
166-    [ $RETVAL -eq 0 -a -d /var/lock/subsys ] && touch $lockfile
167-    if [ -f $lockfile ]; then
168:        restorecon $lockfile
169-    fi
170-}
171-
172-stop() {
173-    if [ ! -f $stop_script ]; then

Hmm, why we don't see it in RHEL6.5. So an apache script executes this init script, right?

On 04/26/2013 11:19 PM, Nathan Kinder wrote:
Console invokes the restart CGI, which calls the service command. 

So yes.

Fixed in selinux-policy-3.7.19-195.el6_4.5

(In reply to comment #20)
> Fixed in selinux-policy-3.7.19-195.el6_4.5

Works great for me, thank you ! Admin server restarts from console and I don`t see Permission denied in logs.

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-2013-0835.html