Problem: myscript, crontab and policy rules for this

Problem: myscript, crontab and policy rules for this

[Tanel Kokk]

I have Fedora Core 2 with SElinux. I added a script into the crontab 
/etc/cron.d/myscript (it includes a line:
0 * * * *		/usr/local/bin/myscript > /dev/null 2>&1)

selinux logs following audit message:
avc:  denied  { transition } for  pid=17845 exe=/usr/sbin/crond 
path=/bin/bash dev=dm-0 ino=2850852 scontext=root:system_r:crond_t 
tcontext=user_u:sysadm_r:sysadm_t tclass=process

I use program audit2allow to generate correct rule to policy:
allow crond_t sysadm_t:process { transition };

I put it into the file domains/misc/local.te and 'make load'

Unfortunately it won't help because same audit log message will appear, 
when cron will try execute myscript.

What I have to do? Why audit2allow won't generate correct rules?

Tanel


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Problem: myscript, crontab and policy rules for this

[Stephen Smalley]

On Wed, 2004-07-28 at 06:07, Tanel Kokk wrote:
> I have Fedora Core 2 with SElinux. I added a script into the crontab 
> /etc/cron.d/myscript (it includes a line:
> 0 * * * *		/usr/local/bin/myscript > /dev/null 2>&1)
> 
> selinux logs following audit message:
> avc:  denied  { transition } for  pid=17845 exe=/usr/sbin/crond 
> path=/bin/bash dev=dm-0 ino=2850852 scontext=root:system_r:crond_t 
> tcontext=user_u:sysadm_r:sysadm_t tclass=process
> 
> I use program audit2allow to generate correct rule to policy:
> allow crond_t sysadm_t:process { transition };
> 
> I put it into the file domains/misc/local.te and 'make load'
> 
> Unfortunately it won't help because same audit log message will appear, 
> when cron will try execute myscript.
> 
> What I have to do? Why audit2allow won't generate correct rules?

First, the transition is wrong, so you don't want to allow it.  It
should be transitioning to system_r:system_crond_t for system cron
jobs.  Try restarting crond via run_init, i.e. run_init
/etc/init.d/crond restart.  That should place it into the proper
starting security context (system_u:system_r:crond_t); yours was running
in root:system_r:crond_t, presumably due to a manual restart without
using run_init.  In FC3 devel, we have also amended the
policy/constraints to allow proper transitioning from
root:system_r:crond_t, so that manual restarts will work without
run_init.

Second, a denial may occur due to a component of the policy other than
the TE rules, as noted in the selinux-doc README and the Configuring the
SELinux Policy report, due to the RBAC configuration or a constraint. 
This is particularly true when changing the SELinux user identity or
role in some manner.  audit2allow just generates TE allow rules from the
audit message; it doesn't try to infer other causes.
  
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Problem: myscript, crontab and policy rules for this

[Tanel Kokk]

Stephen Smalley wrote:

> First, the transition is wrong, so you don't want to allow it.  It
> should be transitioning to system_r:system_crond_t for system cron
> jobs.  Try restarting crond via run_init, i.e. run_init
> /etc/init.d/crond restart.  That should place it into the proper
> starting security context (system_u:system_r:crond_t); yours was running
> in root:system_r:crond_t, presumably due to a manual restart without
> using run_init.  In FC3 devel, we have also amended the
> policy/constraints to allow proper transitioning from
> root:system_r:crond_t, so that manual restarts will work without
> run_init.

Thanks a lot! Everything is OK now after restarting crond with run_init.

> Second, a denial may occur due to a component of the policy other than
> the TE rules, as noted in the selinux-doc README and the Configuring the
> SELinux Policy report, due to the RBAC configuration or a constraint. 
> This is particularly true when changing the SELinux user identity or
> role in some manner.  audit2allow just generates TE allow rules from the
> audit message; it doesn't try to infer other causes.
>   
Understood.

Tanel


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.