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.
Attachment:
signature.asc
Description: This is a digitally signed message part
