selinux-policy-targeted-3.6.12-53.fc11.noarch when a script running from a cron job restarts winbind service using '/sbin/service winbind condrestart' winbind daemon starts in system_cronjob_t domain instead of winbind_t
I added cron_system_entry(winbind_t, winbind_exec_t) to the local policy and the winbind starts properly, but one problem still exists. I redirect output of the service winbind condrestart >/dev/null This generates AVC because MLS levels do not match: type=SYSCALL msg=audit(1246718701.674:10609): arch=40000003 syscall=11 success=yes exit=0 a0=bfa8df49 a1=bfa8dc94 a2=980d858 a3=bfa8dc84 items=0 ppid=25378 pid=25384 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=790 comm="winbind" exe="/bin/bash" subj=system_u:system_r:system_cronjob_t:s0 key=(null) type=AVC msg=audit(1246718701.674:10609): avc: denied { write } for pid=25384 comm="winbind" path="pipe:[621476]" dev=pipefs ino=621476 scontext=system_u:system_r:system_cronjob_t:s0 tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file ---- type=SYSCALL msg=audit(1246718702.026:10610): arch=40000003 syscall=11 success=yes exit=0 a0=8157c10 a1=8157358 a2=81572a8 a3=8157358 items=0 ppid=25391 pid=25392 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=790 comm="winbindd" exe="/usr/sbin/winbindd" subj=system_u:system_r:winbind_t:s0 key=(null) type=AVC msg=audit(1246718702.026:10610): avc: denied { write } for pid=25392 comm="winbindd" path="pipe:[621476]" dev=pipefs ino=621476 scontext=system_u:system_r:winbind_t:s0 tcontext=unconfined_u:system_r:crond_t:s0-s0:c0.c1023 tclass=fifo_file
What as the label on the /etc/init.d/winbind script. This should have worked without the policy change mentioned above. cron jobs are supposed to be able to execute initrc scripts and transition to the proper domains.
ls -Z /etc/init.d/winbind -rwxr-xr-x. root root system_u:object_r:samba_initrc_exec_t:SystemLow /etc/init.d/winbind cron jobs suppose to, but cron_system_entry(winbind_t, winbind_exec_t) is not in standard policy.
cronjobs are supposed to transition to initrc_t which then will transition to winbind_t system_crond_t -> initrc_exec_type -> initrc_t initrc_t -> winbind_exec_t -> winbind_t Do you see any
I run in permissive mode, because I can't make it to work properly at the moment and when service winbind condrestart from cron job I can see winbind running in system_cronjob_t domain and I I get all sort of denials after that.
*** This bug has been marked as a duplicate of bug 509502 ***
I maybe miss something, but how are they duplicate? They are not even close?
oops picked wrong bugzilla.
Vadym is this working for you now?
Only after I added cron_system_entry(winbind_t, winbind_exec_t) into my local policy. This declaration is missing in policy-targeted
Vadym that should not be required, if cron is starting winbind via an initscript. If it is starting the executable directly then it is necessary.
Doesn't look this way. here is crontab entry: 26 * * * * root /etc/init.d/winbind condrestart>/dev/null without cron_system_entry in policy: Jul 28 10:26:02 pegasus CROND[30771]: (root) CMD (/etc/init.d/winbind condrestart>/dev/null) ps -efZ|grep winbind system_u:system_r:system_cronjob_t:SystemLow root 30781 1 0 10:26 ? 00:00:00 winbindd system_u:system_r:system_cronjob_t:SystemLow root 30783 30781 0 10:26 ? 00:00:00 winbindd when the entry is in the policy - all is fine.
I tried this before and it worked for me. My crontab looks like 26 * * * * /etc/init.d/winbind condrestart>/dev/null In F11. and it works. Using selinux-policy-3.6.12-62.fc11 # ls -lZ /etc/init.d/winbind -rwxr-xr-x. root root system_u:object_r:samba_initrc_exec_t:s0 /etc/init.d/winbind Not sure what the "root" entry on your machine was. Miroslav, can you try this on your machine and make sure that winbind is still running as winbind_t after the cron job runs.
[root@pegasus ~]# semanage user -l|grep root root user SystemLow SystemLow-SystemHigh staff_r sysadm_r system_r unconfined_r
Vadym, sorry that was not what I meant. You stated that the crontab on your machine was 26 * * * * root /etc/init.d/winbind condrestart>/dev/null ^^ Is illegal on my machine? Is this a typo?
this is entry from /etc/cron.d/ You have to specify user id there.
Ahhh something different Let me try that out.
Still works for me. Do you have another machine you could try this on?
sure, on this server selinux is enforcing [root@hut ~]# service winbind start Starting Winbind services: [ OK ] [root@hut ~]# ps -efZ|grep winbind unconfined_u:system_r:winbind_t:s0 root 13402 1 0 16:14 ? 00:00:00 winbindd unconfined_u:system_r:winbind_t:s0 root 13404 13402 0 16:14 ? 00:00:00 winbindd [root@hut ~]# cat /etc/cron.d/test 20 * * * * root /etc/init.d/winbind condrestart >/dev/null [root@hut ~]# service crond reload Reloading crond: [ OK ] [root@hut ~]# tail /var/log/cron Jul 28 16:20:01 hut CROND[13562]: (root) CMD (/etc/init.d/winbind condrestart >/dev/null) [root@hut ~]# ps -efZ|grep winbind system_u:system_r:system_cronjob_t:s0 root 13577 1 0 16:20 ? 00:00:00 winbindd system_u:system_r:system_cronjob_t:s0 root 13579 13577 0 16:20 ? 00:00:00 winbindd [root@hut ~]# rpm -q selinux-policy-targeted selinux-policy-targeted-3.6.12-62.fc11.noarch Same.
Well I have been able to recreate this on one machine, here. But I still do not know why. system_cronjob_t should be able to transition to initrc_t. When executing samba_initrc_exec_t What does ps -eZ | grep crond Say?
Found it, Miroslav can you change init_spec_domtrans_script(system_cronjob_t) to init_domtrans_script(system_cronjob_t)
Fixed in selinux-policy-3.6.12-71.fc11
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping