On Thu, 2005-05-26 at 03:39 +0200, Aleksander Adamowski wrote:
> Hi!
>
> I'm having a problem with FC3 strict policy. Basically, I've customised
> the policy to cover all that I need on that system, but there's one last
> denial that I'm unable to remedy:
>
> May 26 03:26:01 machinename kernel: audit(1117070761.996:0): avc:
> denied { transition } for pid=11773 exe=/bin/bash
> path=/home/twiki/bin/mailnotify dev=hda1 ino=51463
> scontext=root:sysadm_r:sysadm_crond_t tcontext=root:system_r:twiki_t
> tclass=process
Note that the above transition involves a role change, not just a type
change. Hence, you are hitting a constraint in policy/constraints that
says that a process may not change roles unless it meets certain
restrictions. The role transition is occurring because you have
declared it as a daemon domain, thus it is trying to transition to the
system_r role for system processes.
Questions:
- Do you truly want this to run in the same domain when it is run from
httpd as when it is run from the cron job? This implies that it has the
same permissions in both cases. For example, I might envision the cron
job as being more trusted (as it was set up by the admin) than the
process spawned from httpd, and I doubt you want a httpd-spawned process
to be able to attack the cron job if it happens to be running
simultaneously. You can define two different domains, with a shared
exec type, such that the cron job will transition to one domain and
httpd will transition to another domain when they run the program.
- Is using daemon_domain truly appropriate here? I'm a little
skeptical.
- Why are you giving it access to unlabeled_t? Suggests some other
problem with your filesystem labels or use of non-labeled fs.
--
Stephen Smalley
National Security Agency
|
