Re: Domains, interpreted languages, and Cron scripts

[Colin Walters]

On Sat, 2004-08-14 at 12:40 -0700, Bill McCarty wrote:

>  I've run into an architectural headache that someone else must
> already have 
>  visited, and perhaps solved. But, I find no mention of the problem in list 
>  archives or elsewhere. 
Actually I think this is the same problem as the "crond/mailman" thread
just above :)

>  I have several Python scripts that run under Cron. Some of these
> scripts 
>  access or modify sensitive data, and so I'd like to define one or more 
>  domains by means of which to limit their privileges.  
Definitely possible.

>  However, the exe name 
>  associated with such scripts is /usr/bin/python2.3, rather than the name of 
>  the script.  
You mean that you see exe=/usr/bin/python2.3 in the audit logs?  That's
just a side effect of the way the kernel interprets the #! header and
executes the script, it doesn't mean all python scripts have to run in
the same domain.

>  Consistent with the principle of least privilege, I'd prefer to 
>  define distinct domains for each script, rather than an overly broad 
>  python_t domain, for instance. 
After creating your domain, just be sure that the context is set
correctly on the executable file, and that you execute it directly.

For example: 

[root@monk root]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:sysadm_r:sysadm_t
[root@monk root]# cat /usr/local/bin/foo.py
#!/usr/bin/python2.3
import os
os.system("id")
[root@monk root]# ls -alZ /usr/local/bin/foo.py
-rwxr-xr-x+ root     root     root:object_r:bin_t              /usr/local/bin/foo.py
[root@monk root]#  /usr/local/bin/foo.py
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:sysadm_r:sysadm_t
[root@monk root]# chcon -t unconfined_exec_t /usr/local/bin/foo.py
[root@monk root]# ls -alZ /usr/local/bin/foo.py
-rwxr-xr-x+ root     root     root:object_r:unconfined_exec_t  /usr/local/bin/foo.py
[root@monk root]# /usr/local/bin/foo.py
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
context=root:sysadm_r:unconfined_t

You can see from the above that when I originally executed the script, I
remained in the security context root:sysadm_r:sysadm_t.  That's because
the script had the bin_t type, and there is no transition.  However,
when I changed the type of the script to unconfined_exec_t, this caused
a transition to root:sysadm_r:unconfined_t (note the different type).

So what you would do is create your own domain foo_script_t, and just
do:
chcon -t foo_script_t /path/to/script

Does that make sense?

>  One idea: Would it be a good thing to modify Run-parts to transition
> to a 
>  domain named for the Cron script it launches? Doing so would seem to solve 
>  my problem, but it might create others <g>. 
I don't think it's necessary to modify run-parts.  Instead, inside the
definition of your foo_script.te file, do something like:

ifdef(`crond.te', `
system_crond_entry(foo_script_exec_t, foo_script_t)
')

system_crond_entry is a macro that causes the transition to happen
automatically.