The system logger is responsible for writing log events in various log files.
Some of these log files are not labeled as var_log_t, but have their domains'
specific logging type set. One of these is cron_log_t.
Allow syslogd_t to write to the cron log files, and introduce a file transition
when the file is just created.
Signed-off-by: Sven Vermeulen <[email protected]>
---
policy/modules/system/logging.te | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/policy/modules/system/logging.te b/policy/modules/system/logging.te
index 696e0c8..b16ddac 100644
--- a/policy/modules/system/logging.te
+++ b/policy/modules/system/logging.te
@@ -490,6 +490,13 @@ optional_policy(`
')
optional_policy(`
+ cron_create_log_files(syslogd_t)
+ cron_generic_log_filetrans_log(syslogd_t, file, "cron.log")
+ cron_setattr_log_files(syslogd_t)
+ cron_write_log_files(syslogd_t)
+')
+
+optional_policy(`
inn_manage_log(syslogd_t)
')
--
1.7.8.6
On 10/29/12 15:16, Sven Vermeulen wrote:
> The system logger is responsible for writing log events in various log files.
> Some of these log files are not labeled as var_log_t, but have their domains'
> specific logging type set. One of these is cron_log_t.
>
> Allow syslogd_t to write to the cron log files, and introduce a file transition
> when the file is just created.
While we already have syslogd doing this for inn logs, your patch makes me question this. Do we really want this? It seems that we would want all of the syslog logs to be var_log_t. If a service does logging itself, it would need a private log type, but if its logging to syslog, the logs should probably still come out var_log_t.
> Signed-off-by: Sven Vermeulen <[email protected]>
> ---
> policy/modules/system/logging.te | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/policy/modules/system/logging.te b/policy/modules/system/logging.te
> index 696e0c8..b16ddac 100644
> --- a/policy/modules/system/logging.te
> +++ b/policy/modules/system/logging.te
> @@ -490,6 +490,13 @@ optional_policy(`
> ')
>
> optional_policy(`
> + cron_create_log_files(syslogd_t)
> + cron_generic_log_filetrans_log(syslogd_t, file, "cron.log")
> + cron_setattr_log_files(syslogd_t)
> + cron_write_log_files(syslogd_t)
> +')
> +
> +optional_policy(`
> inn_manage_log(syslogd_t)
> ')
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Wed, 2012-10-31 at 10:30 -0400, Christopher J. PeBenito wrote:
> On 10/29/12 15:16, Sven Vermeulen wrote:
> > The system logger is responsible for writing log events in various log files.
> > Some of these log files are not labeled as var_log_t, but have their domains'
> > specific logging type set. One of these is cron_log_t.
> >
> > Allow syslogd_t to write to the cron log files, and introduce a file transition
> > when the file is just created.
>
> While we already have syslogd doing this for inn logs, your patch makes me question this. Do we really want this? It seems that we would want all of the syslog logs to be var_log_t. If a service does logging itself, it would need a private log type, but if its logging to syslog, the logs should probably still come out var_log_t.
Why? What is your argument for this?
I could think of one argument to use private types. This will help the
administrator of the service. We can now give him access to only the
service logs as opposed to all generic logs
> > Signed-off-by: Sven Vermeulen <[email protected]>
> > ---
> > policy/modules/system/logging.te | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/policy/modules/system/logging.te b/policy/modules/system/logging.te
> > index 696e0c8..b16ddac 100644
> > --- a/policy/modules/system/logging.te
> > +++ b/policy/modules/system/logging.te
> > @@ -490,6 +490,13 @@ optional_policy(`
> > ')
> >
> > optional_policy(`
> > + cron_create_log_files(syslogd_t)
> > + cron_generic_log_filetrans_log(syslogd_t, file, "cron.log")
> > + cron_setattr_log_files(syslogd_t)
> > + cron_write_log_files(syslogd_t)
> > +')
> > +
> > +optional_policy(`
> > inn_manage_log(syslogd_t)
> > ')
>
On Wed, Oct 31, 2012 at 03:46:17PM +0100, Dominick Grift wrote:
> > While we already have syslogd doing this for inn logs, your patch makes me question this. Do we really want this? It seems that we would want all of the syslog logs to be var_log_t. If a service does logging itself, it would need a private log type, but if its logging to syslog, the logs should probably still come out var_log_t.
>
> Why? What is your argument for this?
>
> I could think of one argument to use private types. This will help the
> administrator of the service. We can now give him access to only the
> service logs as opposed to all generic logs
My first idea was to allow syslogd_t to manage all possible log files
(attribute "logfile"), but grift correctly pointed out that not all log
files are to be managed by the system logger, making this a bit too broad.
Prime examples of this are xserver_log_t, rpm_log_t, portage_log_t,
fsadm_log_t and others. Some of these are only generated by their respective
daemons, others are application log files (not service/daemon, and
definitely not syslog trigered).
Another possibility would be to provide interfaces like
"logging_syslog_log_file" and "logging_syslog_log_dir" which takes two
arguments, one being the type and one being an (optional) name to use for
file name transitions.
In case of cron, this could then be something like:
type cron_log_t;
logging_syslog_log_file(cron_log_t, "cron.log")
If the type is also to be used for directories, something like
type httpd_log_t;
logging_syslog_log_file(httpd_log_t)
logging_syslog_log_dir(httpd_log_t, "apache")
The interface would then assign an attribute "syslogfile" to the type, and
introduce a file transition:
logging_syslog_log_file(`
gen_require(`
attribute syslogfile;
type syslogd_t;
type var_log_t;
')
typeattribute $1 syslogfile;
filetrans_pattern(syslogd_t, var_log_t, $1, file, $2)
logging_log_file($1)
')
In the logging.te, there would be something like:
manage_files_pattern(syslogd_t, syslogfile, syslogfile)
manage_dirs_pattern(syslogd_t, syslogfile, syslogfile)
Is that an option to consider?
Wkr,
Sven Vermeulen