Review request: syslog-ng (syslog replacement daemon)

[Jose Pedro Oliveira]

> On Sat, 2005-05-07 at 19:26 +0100, Jose Pedro Oliveira wrote:
>> > On Sat, 2005-05-07 at 01:29 +0100, José Pedro Oliveira wrote:
>> >>   * Changes a file from another package
>> >>     (/etc/logrotate.d/syslog from the sysklogd rpm)
>> >
>> > Better to figure out how to generalize this.  See my later mail.
>>
>> Don't know how to do it without using alternatives.  The best solution
>> I came up with was to comment the /etc/logrotate.d/syslog lines
>> using triggers.
>> (previous comments in https://bugzilla.fedora.us/show_bug.cgi?id=1332)
>
> The only difference between the two files right now is what pid file
> they cat to figure out what service to restart.  Using a trigger to
> comment all of the sysklogd package's version of this file is *BROKEN*
> as just because a package is installed, doesn't mean it's being used.
> Not to mention that the trigger strikes me as being relatively prone to
> causing problems down the line.

Can we expect that no changes are made to the syslog logrotate file?

Sure it isn't the best solution but it appears to be the one that
is less harmful.  The triggers are only activated during install
and removal of sysklogd or syslog-ng.

> As far as generalizing it, you could do this with a relatively trivial
> change to the initscript.  In the start/stop, create and remove a
> symlink of /var/run/syslog.pid that points to the syslog-ng pidfile.
> Sure, it's a bit hacky, but it's better than sed'ing provided config
> files all the time.

It doesn't work for the following cenario:
  1) FC system with sysklogd
  2) install syslog-ng
  3) stop syslog
  4) start syslog-ng
  5) remove sysklogd
  => no logrotate file (!)

Shouldn't the symlink idea be expanded to "alternatives" ?

>> >>   * currently it doesn't change the use_syslogng SELinux boolean
>> >
>> > I don't see any other packages doing anything like this at the moment,
>> > and I'm not entirely sure how I feel about it.[1]  Looking at what the
>> > boolean allows, I think that some of them at least are valid in the
>> case
>> > of sysklogd where you're using a remote syslog server.  cc'ing Dan to
>> > see if he has an opinion here.
>>
>> As the use_syslogng SELinux boolean is for syslog_ng, I don't see
>> any problem in enabling/disabling it using the post scripts
>> (see the message in trhe fedora-packaging mailing list).
>
> Sometimes, the right answer to how to package a piece of software
> includes getting other things in the distribution fixed.  And in this
> case, I'm not convinced that syslog-ng's basic needs shouldn't be
> covered by the standard syslog policy already, although there may be
> gaps or bugs which should legitimately be looked at.  Let's look at the
> things which the boolean allows:

This is a moving target and I am a newbie when it comes to SELinux.
But in FC3 you wouldn't be able to start syslog-ng without (most of) the
following rules:

	...
	bool use_syslogng false;

	if (use_syslogng) {
	# Allow access to /proc/kmsg for syslog-ng
	allow syslogd_t proc_t:dir search;
	allow syslogd_t proc_kmsg_t:file { getattr read };
	allow syslogd_t kernel_t:system { syslog_mod syslog_console };
	allow syslogd_t self:capability { sys_admin chown fsetid };
	allow syslogd_t var_log_t:dir { create setattr };
	}

Source:
  RPM: selinux-policy-targeted-sources-1.17.30-2.96
  File: /etc/selinux/targeted/src/policy/domains/program/syslogd.te

Hoping that Dan Walsh will answer the following questions:

>   if (use_syslogng) {
>   # Allow access to /proc/kmsg for syslog-ng
>   allow syslogd_t proc_t:dir search;
>   allow syslogd_t proc_kmsg_t:file { getattr read };
>
> It looks like klogd uses /proc/kmsg by default for accessing kernel
> messages, so why should this be covered under the boolean?
>
>   allow syslogd_t kernel_t:system { syslog_mod syslog_console };
>   allow syslogd_t self:capability { sys_admin chown fsetid };
>
> This looks like it's already allowed for klogd
>
>   allow syslogd_t var_log_t:dir { create setattr };
>
> sysklogd would need this functionality as well if it is allowed to
> create arbitrary, not existing already log files.
>
>   allow syslogd_t syslogd_port_t:tcp_socket name_bind;
>
> You want to allow this for remote logging with sysklogd as well
>
>   allow syslogd_t rsh_port_t:tcp_socket name_connect;
>
> Not clear at all one why syslog-ng would need access to bind to the rsh
> socket.  Source grepping a bit shows that it's being used for network
> logging.  Aside from the brokenness of re-using a standard port, having
> people be aware of the need to allow the operation if they configure
> syslog-ng in this fashion doesn't strike me as a bad idea.
>
> Jeremy
>

jpo
-- 
José Pedro Oliveira
* mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo *
* gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B *