Domains, interpreted languages, and Cron scripts

[Bill McCarty]

Hi Russ, Colin, and all,

--On Sunday, August 15, 2004 2:03 AM -0400 Colin Walters 
<walters at redhat.com> wrote:

> Actually I think this is the same problem as the "crond/mailman" thread
> just above :)

Yes, I believe that the new thread appeared after I'd searched for 
messages. But, perhaps my search was less effective than I'd hoped <g>.

>> 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.

Ah! I hadn't considered that the behavior of a python script using a 
shebang (#!) and one invoking python with a script name as a an argument 
might differ. The distinction is obvious in retrospect. Part of my 
confusion arose because one of my files was incorrectly labeled. As someone 
wrote, it's not what you don't know that gets you, it's what you think you 
know that isn't really so <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)
> ')

Thanks! I hadn't noticed that convenient macro. FYI, it looks like its 
definition already checks for crond.te:

# When system_crond_t domain executes a type $1 executable then transition 
to
# domain $2, allow $2 to interact with crond_t as well.
define(`system_crond_entry', `
ifdef(`crond.te', `
domain_auto_trans(system_crond_t, $1, $2)
allow $2 crond_t:fifo_file { getattr read write ioctl };
# a rule for privfd may make this obsolete
allow $2 crond_t:fd use;
allow $2 crond_t:process sigchld;

Cheers,

-- 
Bill McCarty, Ph.D.
Professor of Information Technology
Azusa Pacific University