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 at 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 at monk root]# cat /usr/local/bin/foo.py
#!/usr/bin/python2.3
import os
os.system("id")
[root at 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 at 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 at monk root]# chcon -t unconfined_exec_t /usr/local/bin/foo.py
[root at 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 at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-selinux-list/attachments/20040815/d15544a9/attachment.sig>