avc denied from logrotate

[Richard Hally]

Here are the avc denied messages from doing a logrotate.
I get an error message when I try to do the logrotate in enforcing mode. I
changed to
permissive mode, did the logrotate and the resulting messages are attached:

Richard Hally

[Stephen Smalley]

On Fri, 2004-03-26 at 02:39, Richard Hally wrote:
> Here are the avc denied messages from doing a logrotate.
> I get an error message when I try to do the logrotate in enforcing mode. I
> changed to
> permissive mode, did the logrotate and the resulting messages are attached:

With regard to the /etc/init.d/cups condrestart line in
/etc/logrotate.d/cups, should logrotate.te include:
domain_auto_trans(logrotate_t, initrc_exec_t, initrc_t)
so that the init script runs in the proper domain, and any subsequent
daemon restarts are transitioned to the right domain?  That would run
the init script in initrc_t rather than directly in logrotate_t, and
eliminate the need for the various domain_auto_trans(logrotate,
foo_exec_t, foo_t) rules that I see sprinkled about various daemon .te
files, since the usual transition from initrc_t would handle it.

[Stephen Smalley]

On Fri, 2004-03-26 at 02:39, Richard Hally wrote:
> Here are the avc denied messages from doing a logrotate.
> I get an error message when I try to do the logrotate in enforcing mode. I
> changed to
> permissive mode, did the logrotate and the resulting messages are attached:

With regard to the innd_log_t denial, is this file written by both
syslogd and innd?  If it is only written by syslogd, then it shouldn't
be labeled innd_log_t.  If it can be written by either daemon depending
on configuration, then perhaps syslogd.te should include
'create_append_log_file(syslogd_t, logfile)'.

Looks like logrotate needs can_exec(logrotate_t, logfile), although I
find that disturbing.  Possibly need another domain with less
permissions that it can transition to when executing these temporary
files.

Can you enable syscall auditing (boot with audit=1) and re-run
logrotate, so that we can see the actual pathname parameters for some of
these calls?  The slrnpull_spool_t ones look odd, as I wouldn't expect
that type on log files, and slrnpull does have its own log type.