Been a while since I've had time to deal with SELinux, but am getting back to it. Seems that the selinux-logwatch module does not contain the correct file context label for the logwatch executable, /usr/sbin/logwatch.pl When running logwatch from cron, this results in the process running as system_cronjob_t instead of the correct logwatch_t. This produces a myriad of denials and improper behavior by logwatch when launched from cron. Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4666): avc: denied { write } for pid=3629 comm="logwatch.pl" name="logwatch" dev="sda3" ino=6317669 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4667): avc: denied { add_name } for pid=3629 comm="logwatch.pl" name="logwatch.SPo7fGYl" scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4668): avc: denied { create } for pid=3629 comm="logwatch.pl" name="logwatch.SPo7fGYl" scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir Oct 18 00:05:01 iax kernel: type=1400 audit(1350540301.785:4669): avc: denied { setattr } for pid=3629 comm="logwatch.pl" name="logwatch.SPo7fGYl" dev="sda3" ino=6292067 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=dir Oct 18 00:05:02 iax kernel: type=1400 audit(1350540302.024:4670): avc: denied { create } for pid=3631 comm="sh" name="maillog-archive" scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=file Oct 18 00:05:02 iax kernel: type=1400 audit(1350540302.024:4671): avc: denied { append open } for pid=3631 comm="sh" path="/var/cache/logwatch/logwatch.SPo7fGYl/maillog-archive" dev="sda3" ino=6292403 scontext=system_u:system_r:system_cronjob_t tcontext=system_u:object_r:logwatch_cache_t tclass=file By adding a file context rule to label /usr/sbin/logwatch.pl as logwatch_exec_t the process is then allowed to transition to logwatch_t and then runs normally
I'm guessing this is due to a move of the executable to /usr/sbin/logwatch.pl. The current policies show that this script is expected in /usr/share/logwatch/scripts/logwatch\.pl: /usr/share/logwatch/scripts/logwatch\.pl -- gen_context(system_u:object_r:logwatch_exec_t, s0) Full: /usr/sbin/logcheck -- gen_context(system_u:object_r:logwatch_exec_t,s0) /usr/sbin/epylog -- gen_context(system_u:object_r:logwatch_exec_t,s0) /usr/share/logwatch/scripts/logwatch\.pl -- gen_context(system_u:object_r:logwatch_exec_t, s0) /var/cache/logwatch(/.*)? gen_context(system_u:object_r:logwatch_cache_t, s0) /var/lib/logcheck(/.*)? gen_context(system_u:object_r:logwatch_cache_t,s0) /var/lib/epylog(/.*)? gen_context(system_u:object_r:logwatch_cache_t,s0) /var/lock/logcheck.* gen_context(system_u:object_r:logwatch_lock_t,s0) /var/run/epylog\.pid -- gen_context(system_u:object_r:logwatch_var_run_t,s0) The full filecontext file shows that there is no rule in the logwatch.fc policy covering /usr/sbin/logwatch.pl. Should we change the policy to include both locations or simply update it to have the new location?
Just adding the context to it should be sufficient; we'll need to "support" some form of backwards compatibility anyhow. I've sent it upstream, and since it's a contrib module it'll get in rather quickly.
Merged upstream, will be in r6
In hardened-dev, r6 release
In main tree, ~arch'ed
r8 is now stable
