Bug 873885

Ticket #00738924 is cross-field in the Red Hat customer portal.

/var/lib/z-push(/.*)?  gen_context(system_u:object_r:httpd_var_lib_t,s0)
/var/log/z-push(/.*)?          gen_context(system_u:object_r:httpd_log_t,s0)


These two might not be correct.

/usr/share/z-push(/.*)?                        gen_context(system_u:object_r:httpd_sys_content_t,s0)
/etc/z-push(/.*)?                      gen_context(system_u:object_r:httpd_sys_content_t,s0)

Which paths does Apache need to execute other then the ones in /usr/bin.

I wonder about httpd_sys_content_t because phpMyAdmin doesn't have that
context right now?! Z-Push is like phpMyAdmin or WordPress, just to give
you an impression, however it has CLI scripts for management additionally.

So httpd does not execute or read anything in these directories?

Just compare the RPMs and the file contexts yourself:

- http://buildsys.rpmfusion.org/plague-results/el-6-rpmfusion_free/z-push/2.0.5-1.el6/noarch/
- http://kojipkgs.fedoraproject.org//packages/phpMyAdmin/3.5.3/1.el6/noarch/

/etc/phpMyAdmin =~ /etc/z-push -> system_u:object_r:etc_t:s0
/usr/share/phpMyAdmin =~ /usr/share/z-push -> system_u:object_r:usr_t:s0

However, phpMyAdmin seems to be fine and does not cause any trouble. Does it
mean that the Apache SELinux policy has already so much loosed that it works
without adaptions (when ignoring the write issue in z-push)?! Or should these
directories be added for phpMyAdmin because they are missing by accident? I'm
sorry for doing this comparision, however it is similar software...

I agree with httpd_log_t for /var/log/z-push, cacti or others seem to use the
same file context here.

Finally, I'm  abit irritated about httpd_var_lib_t for /var/lib/z-push, as
httpd_sys_rw_content_t is e.g. in use for /var/lib/koji - so where's the 
difference? Apache must be here able to create, read & delete sub-directories, 
create, read, delete and modify files.

Daniel or Miroslav: Ping?

Well /var/lib/koji might be labeled differently also.  I am not sure there is much of a difference between httpd_sys_content_t, and httpd_var_lib_t, more domains are allowed to read httd_sys_content_t.  cgi scripts are not allowed to use httpd_var_lib_t.

# sesearch -CA -s httpd_sys_script_t -t httpd_var_lib_t
# sesearch -CA -s httpd_t -t httpd_var_lib_t
Found 3 semantic av rules:
   allow httpd_t httpd_var_lib_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; 
   allow httpd_t httpd_var_lib_t : dir { ioctl read write create getattr setattr lock unlink link rename add_name remove_name reparent search rmdir open } ; 
   allow httpd_t file_type : filesystem getattr ; 


Where as

sesearch -CA -s httpd_sys_script_t -t httpd_sys_rw_content_t | wc -l
11

In RHEL6 policy httpd_t is allowed to read files labeled etc_t and usr_t.

So, it should work with

/etc/z-push(/.*)?                      gen_context(system_u:object_r:etc_t,s0)

/usr/share/z-push(/.*)?                      gen_context(system_u:object_r:user_t,s0)

/var/lib/z-push(/.*)?  gen_context(system_u:object_r:httpd_var_lib_t,s0)
/var/log/z-push(/.*)?          gen_context(system_u:object_r:httpd_log_t,s0)

I'm currently playing with the proposed stuff from above:

  semanage fcontext -a -f 'all files' -t httpd_log_t '/var/log/z-push(/.*)?'

However this causes (after "restorecon -v -R /var/log/z-push") this:

type=AVC msg=audit(1353494956.203:19460): avc:  denied  { write } for  pid=10246 comm="httpd" name="z-push.log" dev=dm-0 ino=28297 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_log_t:s0 tclass=file

Is it correct that httpd_t is not allowed to write httpd_log_t? Should this
still be solved within httpd*_t then?

Yes, this is correct. Z-Push should append own logs or we will need to change labeling.

Z-Push uses PHP's file_put_contents() which creates or appends. Unfortunately,
it is sometimes necessary to create new log files that can't be covered already
with packaging. So which other labeling do you prefer? Zarafa itself recommends
here to use httpd_sys_rw_content_t - which seems a) strange and b) wrong to me,
but feel free to correct me, please.

   allow httpd_t httpd_log_t : file { ioctl read create getattr lock append open } ; 

It does have create and append.  I guess this  could be a problem then.

Joe, A while ago didn't we decide that preventing apache from writing its own logs is not necessary?  IE It would be ok if httpd_t could clear a log file.

Wouldn't an allow for write bear the risk that e.g. a PHP script could truncate
the Apache access_log?

I agree. I believe we should change labeling to httpd_sys_rw_content_t as we have it for Zarafa. Or we could discuss httpd_rw_log_t for these projects.

Ah: Drupal, Subversion, DokuWiki, Zabbix and Moodle use httpd_sys_rw_content_t.
If the label would be fine for you, I would run some tests with that myself...

Ping? Shall I try with httpd_sys_rw_content_t? And would this context be in
general suitable for you?

You can also test the latest build. The labeling should be there.

The latest build that includes httpd_sys_rw_content_t is which RPM package 
version of the policy?

(In reply to comment #21)
> The latest build that includes httpd_sys_rw_content_t is which RPM package 
> version of the policy?

selinux-policy-3.7.19-183.el6

Using selinux-policy-3.7.19-183.el6 the first login with Z-Push fails like this:

type=AVC msg=audit(1354300349.730:21012): avc:  denied  { unix_read unix_write } for  pid=2742 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300349.730:21012): arch=c000003e syscall=64 success=no exit=-13 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2742 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300352.388:21013): avc:  denied  { unix_read unix_write } for  pid=2744 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300352.388:21013): arch=c000003e syscall=64 success=no exit=-13 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2744 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300354.838:21014): avc:  denied  { unix_read unix_write } for  pid=2743 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300354.838:21014): arch=c000003e syscall=64 success=no exit=-13 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2743 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300360.924:21015): avc:  denied  { unix_read unix_write } for  pid=2737 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300360.924:21015): arch=c000003e syscall=64 success=no exit=-13 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2737 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

system_u:system_r:zarafa_server_t:s0 root 1560  1.0  1.1 389264 22492 ?        Sl   19:22   0:07 /usr/bin/zarafa-server -c /etc/zarafa/server.cfg
system_u:system_r:zarafa_deliver_t:s0 root 1581 0.0  0.0 225052  1896 ?        S    19:22   0:00 /usr/bin/zarafa-dagent -d -c /etc/zarafa/dagent.cfg
system_u:system_r:zarafa_gateway_t:s0 root 1590 0.0  0.1 204888  2408 ?        S    19:22   0:00 /usr/bin/zarafa-gateway -c /etc/zarafa/gateway.cfg
system_u:system_r:zarafa_ical_t:s0 root   1600  0.0  0.1 201308  2384 ?        S    19:22   0:00 /usr/bin/zarafa-ical -c /etc/zarafa/ical.cfg
system_u:system_r:initrc_t:s0   root      1610  0.0  0.2 342804  4460 ?        Sl   19:22   0:00 /usr/bin/zarafa-licensed -c /etc/zarafa/licensed.cfg
system_u:system_r:zarafa_monitor_t:s0 root 1621 0.0  0.3 406012  6404 ?        Sl   19:22   0:00 /usr/bin/zarafa-monitor -c /etc/zarafa/monitor.cfg
system_u:system_r:initrc_t:s0   root      1633  0.7  0.7 425492 13860 ?        Sl   19:22   0:05 /usr/bin/zarafa-search -c /etc/zarafa/search.cfg
system_u:system_r:zarafa_spooler_t:s0 root 1644 0.0  0.2 302556  5288 ?        Sl   19:22   0:00 /usr/bin/zarafa-spooler -c /etc/zarafa/spooler.cfg

Note, that with Zarafa 7.1.x, zarafa-indexer is replaced by zarafa-search, if that is relevant somehow.

And as said, Z-Push 2.0.x uses the php-process RPM package and makes use of SHM/SEM/IPC through these PHP modules.

srw-rw-rw-. root root system_u:object_r:zarafa_server_var_run_t:s0 /var/run/zarafa
-rw-r--r--. root root system_u:object_r:zarafa_deliver_var_run_t:s0 /var/run/zarafa-dagent.pid
-rw-r--r--. root root system_u:object_r:zarafa_gateway_var_run_t:s0 /var/run/zarafa-gateway.pid
-rw-r--r--. root root system_u:object_r:zarafa_ical_var_run_t:s0 /var/run/zarafa-ical.pid
srw-rw----. root root system_u:object_r:var_run_t:s0   /var/run/zarafa-licensed
-rw-r--r--. root root system_u:object_r:initrc_var_run_t:s0 /var/run/zarafa-licensed.pid
-rw-r--r--. root root system_u:object_r:zarafa_monitor_var_run_t:s0 /var/run/zarafa-monitor.pid
srw-rw----. root root system_u:object_r:zarafa_server_var_run_t:s0 /var/run/zarafa-prio
srw-rw-rw-. root root system_u:object_r:var_run_t:s0   /var/run/zarafa-search
-rw-r--r--. root root system_u:object_r:initrc_var_run_t:s0 /var/run/zarafa-search.pid
-rw-r--r--. root root system_u:object_r:zarafa_server_var_run_t:s0 /var/run/zarafa-server.pid
-rw-r--r--. root root system_u:object_r:zarafa_spooler_var_run_t:s0 /var/run/zarafa-spooler.pid

Some more stuff when having SELinux permissive:

type=LOGIN msg=audit(1354300801.355:21018): pid=2877 uid=0 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 old auid=4294967295 new auid=0 old ses=4294967295 new ses=4
type=USER_START msg=audit(1354300801.357:21019): user pid=2877 uid=0 auid=0 ses=4 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=CRED_DISP msg=audit(1354300801.385:21020): user pid=2877 uid=0 auid=0 ses=4 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=USER_END msg=audit(1354300801.386:21021): user pid=2877 uid=0 auid=0 ses=4 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_close acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
type=AVC msg=audit(1354300813.135:21022): avc:  denied  { unix_read unix_write } for  pid=2738 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300813.135:21022): arch=c000003e syscall=64 success=no exit=-13 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2738 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300816.862:21023): avc:  denied  { unix_read unix_write } for  pid=2739 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300816.862:21023): arch=c000003e syscall=64 success=no exit=-13 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2739 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300820.700:21024): avc:  denied  { unix_read unix_write } for  pid=2740 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300820.700:21024): arch=c000003e syscall=64 success=no exit=-13 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2740 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=MAC_STATUS msg=audit(1354300876.178:21025): enforcing=0 old_enforcing=1 auid=0 ses=1
type=SYSCALL msg=audit(1354300876.178:21025): arch=c000003e syscall=1 success=yes exit=1 a0=3 a1=7fffbac2d0b0 a2=1 a3=fffffff8 items=0 ppid=1921 pid=2907 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="setenforce" exe="/usr/sbin/setenforce" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1354300879.073:21026): avc:  denied  { unix_read unix_write } for  pid=2741 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=AVC msg=audit(1354300879.073:21026): avc:  denied  { associate } for  pid=2741 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300879.073:21026): arch=c000003e syscall=64 success=yes exit=163845 a0=14 a1=3 a2=3b6 a3=7f13f420c850 items=0 ppid=2735 pid=2741 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300879.074:21027): avc:  denied  { read write } for  pid=2741 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
type=SYSCALL msg=audit(1354300879.074:21027): arch=c000003e syscall=65 success=yes exit=0 a0=28005 a1=7fff7c8dbf10 a2=3 a3=7f13f420c850 items=0 ppid=2735 pid=2741 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300879.074:21028): avc:  denied  { associate } for  pid=2741 comm="httpd" key=30  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm
type=SYSCALL msg=audit(1354300879.074:21028): arch=c000003e syscall=29 success=yes exit=0 a0=1e a1=0 a2=0 a3=7f13f420d4b0 items=0 ppid=2735 pid=2741 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300879.077:21029): avc:  denied  { unix_read unix_write } for  pid=2741 comm="httpd" key=30  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm
type=AVC msg=audit(1354300879.077:21029): avc:  denied  { read write } for  pid=2741 comm="httpd" key=30  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm
type=AVC msg=audit(1354300879.077:21029): avc:  denied  { read write } for  pid=2741 comm="httpd" path=2F535953563030303030303165202864656C6574656429 dev=tmpfs ino=0 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file
type=SYSCALL msg=audit(1354300879.077:21029): arch=c000003e syscall=30 success=yes exit=139723251134464 a0=0 a1=0 a2=0 a3=7f13f420d4b0 items=0 ppid=2735 pid=2741 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300882.293:21030): avc:  denied  { associate } for  pid=2742 comm="httpd" key=30  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm
type=SYSCALL msg=audit(1354300882.293:21030): arch=c000003e syscall=29 success=yes exit=0 a0=1e a1=0 a2=0 a3=7f13f420d4b0 items=0 ppid=2735 pid=2742 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300882.303:21031): avc:  denied  { unix_read unix_write } for  pid=2742 comm="httpd" key=30  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm
type=AVC msg=audit(1354300882.303:21031): avc:  denied  { read write } for  pid=2742 comm="httpd" key=30  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm
type=SYSCALL msg=audit(1354300882.303:21031): arch=c000003e syscall=30 success=yes exit=139723253501952 a0=0 a1=0 a2=0 a3=7f13f420d4b0 items=0 ppid=2735 pid=2742 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1354300897.141:21032): avc:  denied  { read write } for  pid=2744 comm="httpd" path=2F535953563030303030303165202864656C6574656429 dev=tmpfs ino=0 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_tmpfs_t:s0 tclass=file
type=SYSCALL msg=audit(1354300897.141:21032): arch=c000003e syscall=30 success=yes exit=139723253501952 a0=0 a1=0 a2=0 a3=7f13f420d4b0 items=0 ppid=2735 pid=2744 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

Aha! All the stuff above seems to only happen when trying to authenticate with an invalid username/password combination?!

You have this service running as an unconfined user, as opposed to an init script?

Are you running stuff as the user and outside of httpd?

You probably do not want it running as unconfined_t.

Which service? Z-Push consists out of PHP scripts which are run by mod_php
inside of Apache. Z-Push uses some SHM/SEM/IPC calls from PHP. Zarafa itself
is almost completely running zarafa*_t contexts (see above). What I did is
a standard setup of Zarafa 7.1.1 + Z-Push 2.0.5, not more and not less...

How would this run on boot?  Is there a service running?

ps -eZ | grep unconfined_t

I would bet you find services running as the user label.  Not initrc_t or zarafa_t

# ps -eZ | grep unconfined_t
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3431 pts/0 00:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3454 pts/0 00:00:00 ps
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3455 pts/0 00:00:00 grep
#

But: "tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm", so please notice the "tclass=shm" or what are you hunting for?

Right apache process attempted to connect to a shm owned by an unconfined_t process.  Can you run your test again and see if you get the same AVC's or if it works now.

Still the same. And I think, I know the cause: z-push-top. It uses SHM, too.
But it is normally run by root interactively on the shell, thus unconfined_t, 
right?

Any ideas?

Additionally:

type=AVC msg=audit(1354531843.569:25514): avc:  denied  { create } for  pid=10330 comm="httpd" name="7" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1354531843.569:25514): arch=x86_64 syscall=mkdir success=no exit=EACCES a0=7f13f4db5e50 a1=1ff a2=8 a3=5 items=0 ppid=2735 pid=10330 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid3D48 fsgid=48

And even more:

type=AVC msg=audit(1354328765.29:21716): avc:  denied  { read } for  pid=4803 comm="logrotate" name="z-push" dev=vda1 ino=263597 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:httpd_sys_rw_content_t:s0 tclass=dir

type=SYSCALL msg=audit(1354328765.29:21716): arch=x86_64 syscall=open success=no exit=EACCES a0=7fff487d9a90 a1=90800 a2=10abd00 a3=26 items=0 ppid=4801 pid=4803 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=93 comm=logrotate exe=/usr/sbin/logrotate subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)

I feel we have to work on this more in detail somehow...

Which is why /var/log/z-push should be httpd_log_t and should be opened for append and not write.

Miroslav we have 

manage_dirs_pattern(httpd_t, httpd_var_lib_t, httpd_var_lib_t)

In Fedora.

Yes z-push-top is communicating with a service running under apache would cause this AVC.  

Does z-push-top interact with the apache server when you are authenticating?
(Comment 26)

(In reply to comment #37)
> Which is why /var/log/z-push should be httpd_log_t and should be opened for
> append and not write.

Actually PHP offers FILE_APPEND for http://php.net/file_put_contents which is
also used by upstream, however the underlying C implementation does something 
else. I'll discuss with upstream here, but I'm also open for other ideas...

> Yes z-push-top is communicating with a service running under apache would
> cause this AVC.  
> 
> Does z-push-top interact with the apache server when you are authenticating?
> (Comment 26)

Yes and no: Accessing http://.../Microsoft-Server-ActiveSync is usually called
by mobile devices and Z-Push saves the connection information (like username,
device type, activity itself) to semaphores (or so). At the same time, there
is z-push-top (like top(1)) which can be used by administrators on the command 
line to display the devices that are currently connected by HTTP(S). From what
I get, the semaphore stuff is created by that process which is run first. So
when I run z-push-top before the HTTP, I get for each wrong authentication via
HTTP an AVC denied. If HTTP is run before z-push-top, everything seems to be
fine.

Would it help for you, if you get a demo VM for KVM or access to such a system?

Oh and z-push-top does not ask for any credentials, it's simply run as root.

No that is a good description but not something I want.  IE Allowing apache processes to connect to users (especially unconfined ones) shared memory.  I wonder if this is something that is pretty unlikely to happen in the field.  Run z-push-top and then start the apache service, versus the apache service running and a user does z-push-top.

As far as I understand Z-Push, it does not depend on when the Apache starts,
but only on when the first device connects via HTTP. Means you can't do any
useful debugging/monitoring anymore, if the connection interval of the mobile 
devices is not "push", but only every few hours for example. However, if I get 
Zarafa in their (incomplete) Z-Push documentation right, they just ignore that 
case. But hey...they also not care about SELinux that much, but simply advice
to switch to permissive or disable it if needed. The scenario I run into is
IMHO a valid common situation - at least when setting it up the first time or
when doing migrations.

So we end up needing a boolean for this, then.  httpd_use_zarafa?

Uhm. Let me first cross-check if there is really need to create semaphores
when running z-push-top. If I get things right meanwhile, only Apache should 
write or create them. Means it maybe could get solved by fixing the code. I
will talk to upstream.

PHP: file_put_contents("test.log", "test\n", FILE_APPEND);
strace: open("/tmp/test.log", O_WRONLY|O_CREAT|O_APPEND, 0666) = 3

PHP file_put_contents("test.log", "test\n");
strace: open("/tmp/test.log", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3

The first is used in Z-Push code, but why does SELinux complain here about
"write"? I'm not a C developer, but open(2) doesn't leave so many choices?!

Additionally I'm in doubt that labeling /var/lib/z-push with httpd_var_lib_t is a good idea:

type=AVC msg=audit(1355129553.305:38699): avc:  denied  { create } for  pid=12761 comm="httpd" name="6" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_var_lib_t:s0 tclass=dir
type=SYSCALL msg=audit(1355129553.305:38699): arch=c000003e syscall=83 success=no exit=-13 a0=7f13f4dce9a0 a1=1ff a2=8 a3=5 items=0 ppid=2735 pid=12761 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

Any idea or explanation regarding comment #44?

- First of all, I would like to avoid a SELinux boolean, if somehow possible.
- https://jira.zarafa.com/browse/ZP-268 tells that semaphores are not friendly.
- According to some knowledged guys on Freenode #php, all appends in PHP are
  implemented as write via the streams API somehow. Theoretically rewind() is
  possible in PHP for any opened stream. So maybe Joe can confirm or correct
  this statement?
- Couldn't we label /usr/sbin/z-push-{admin,top} as zpush_exec_t, which causes
  semaphores as zpush_t via transition and httpd_t is allowed to access them in 
  general? How about zpush_log_t for /var/log/z-push which allows also the 
  problematic write, not only append and is additionally nice to logrotate?
  And zpush_var_lib_t for /var/lib/z-push which could be managed by httpd_t
  and by zpush_exec_t as needed? Because httpd_var_lib_t doesn't seem to be
  good (loose) enough according to comment #45.

zpush_log_t seems to be the best solution.

Does httpd execute /usr/sbin/z-push or /usr/sbin/zpush-admin?

policy_module(myzpush, 1.0)

gen_require(`
type httpd_t;
')

type zpush_log_t;
logging_log_file(zpush_log_t)

manage_dirs_pattern(httpd_t, zpush_log_t, zpush_log_t)
manage_files_pattern(httpd_t, zpush_log_t, zpush_log_t)
manage_lnk_files_pattern(httpd_t, zpush_log_t, zpush_log_t)

# Might also need

manage_dirs_pattern(httpd_sys_script_t, zpush_log_t, zpush_log_t)
manage_files_pattern(httpd_sys_script_t, zpush_log_t, zpush_log_t)
manage_lnk_files_pattern(httpd_sys_script_t, zpush_log_t, zpush_log_t)

Any chance to test it with the latest RHEL6.5 builds?

Very brief testing seems to suggest that it goes well, but give me a day before closing this. Unless I will start to shout loudly in a week or so, you can consider this bug fixed.

Whoops, I am not a reporter of this bug, so I cannot decide when it has been fixed. Robert, can you check with selinux-policy-targeted-3.7.19-216.el6.noarch?

Matěj, did you also start z-push-top(1) before doing the first request via
ActiveSync (see first comments)?

(In reply to Robert Scheck from comment #52)
> Matěj, did you also start z-push-top(1) before doing the first request via
> ActiveSync (see first comments)?

I did.

So how does it work?

Using z-push-2.0.9-1.el6.noarch, z-push-zarafa-2.0.9-1.el6.noarch as well as
selinux-policy-targeted-3.7.19-231.el6.noarch this issue is same good/bad like
every time before...it simply does not work. Z-Push can not write to its log
files in /var/log/z-push and if you run z-push-top(1) before doing the frist
HTTP request to Z-Push you additionally still get:

type=AVC msg=audit(1386859197.948:42): avc:  denied  { unix_read unix_write } for  pid=1878 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem

Conclusion: Current SELinux policy in RHEL 6.5 doesn't solve this IMHO. I also
did not see any booleans, restorecon -v -R /var/{log,lib}/z-push did not show
any changed contexts.

It has not been approved for RHEL6.5. Ok we have 

type=AVC msg=audit(1386859197.948:42): avc:  denied  { unix_read unix_write } for  pid=1878 comm="httpd" key=20  scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem

which we need to solve.

(In reply to Miroslav Grepl from comment #57)
> It has not been approved for RHEL6.5. Ok we have 
> 
> type=AVC msg=audit(1386859197.948:42): avc:  denied  { unix_read unix_write
> } for  pid=1878 comm="httpd" key=20 
> scontext=unconfined_u:system_r:httpd_t:s0
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=sem
> 
> which we need to solve.

No, it is unfortunately not that easy:

1. /usr/sbin/z-push-{top,admin} are always run at the shell and will create a
   semaphore if none exists. Right now they are unconfined_t of course.
2. Apache runs PHP code from /usr/share/z-push which will create a semaphore
   if none exists. If semaphores already exist it must be able to access them,
   even if the semaphores were created by 1. and not by 2. This is right now
   not possible and causes the above AVC message.
3. The logging issue is IMHO still open thus append vs. trunc in PHP/C, see
   comment #44.

Can we please clarify if we will have an own Z-Push policy (or extend the
current Zarafa one even Z-Push can be used without Zarafa but other backends)
vs. weakening the SELinux policy by allowing the semaphore stuff or logging
things simply?

If so, where will I start? Labeling /usr/sbin/z-push*, /var/{lib,log}/z-push 
with an individual context, add a type transition for /usr/sbin/z-push* to
a z-push domain that httpd is allowed to fully manage as well and look for
possible further AVCs?

I believe it will need to be resolved by a Z-Push policy.

We will need to go with a local policy in RHEL6 and see to get a solution in RHEL7.