using lire-20010629 on RedHat Linux 7.0

[Francis J. Lacoste]

On Mon, Jul 02, 2001 at 12:59:00PM +0200, Wytze van der Raay wrote:
> 
> > Alternatively, if you don't care about somebody compromising
> > your system, you may set I_DONT_CARE_ABOUT_SECURITY='yes' in
> > $HOME/.lirerc to turn off this security check.
> 
> In general I do care about somebody compromising my systems,
> but on the other hand I am not convinced that running lire as
> root will necessarily compromise my system (I do have some trust
> in you logreport developers :-)). So the variable name you're
> suggesting is a bit strong for my taste ... how about
> ALLOW_LIRE_RUNNING_AS_ROOT='yes' ?

:) 

Ok, I'll euphemize the variable. You are somewhat correct in
saying that running lire as root don't necessarily compromise
the system. It's just that lire does many operations (more when
generating PDF) that it's sure that there is potential for
symlinks abuse somewhere or some other race conditions that could
be use by another user to compromise the system when the administrator
runs lire as root. But since lire doesn't cross security boundaries
(except for the responder) the risk is limited. I would be very
worried though if somebody runs the responder as root.

> 
> 
> Joost van Baal wrote:
> 
> > > su -e 'cat /var/log/messages' | lr_run lr_log2report ...
> >
> > Which assumes the user running this can su without giving a password,
> > if this is being run from cron.  (This can be done using pam.)
> > Another alternative is using sudo.
> 
> If you set up su or sudo to allow a process to gain root privileges
> without explicitly having to enter a password, I do not believe that
> you have gained much security. Perhaps I'm a little old-fashioned
> in that.

I wouldn't recommend that either. The su was for interactive use
where the user can enter the root password (or his own if using
sudo)

> 
> > My favourite solution, however, is changing the syslog and logrotate
> > configuration, so that the logs are groupreadable, and adding
> > lire to the owning group.  I don't know the details of the way Redhat
> > handles this, unfortunately.  I believe Erik Troan's logrotate(8) is
> > used?
> 
> Yes, RedHat uses logrotate(8) for logfile rotation. However, logrotate
> does not influence the owner/group/permission by which the logfiles
> are created, it simply renames them. The original owner/group/permission
> is set by the process creating the file, which varies:
>     sendmail    uses syslog, so it's syslogd
>     httpd       writes its logs directly
>     named       depends on /etc/named.conf, typically writes its logs
>                 directly, but may also be configured to use syslog
> 
> The one that is usually causing trouble on my sites is sendmail.
> RedHat starts up syslogd from /etc/rc.d/init.d/syslog after setting
> the umask to 077. Thus maillog files will be created as root/root,
> permission rw-------. So, just adding lire to the owning group (root)
> isn't enough, one must also change the startup script to loosen up
> the umask to 037. While this is all trivial to the seasoned sysadmin,
> it is not for the average RH administrator I think, who is used to
> dropping in new rpm's as they are released by RedHat and not so much
> to maintaining deviations from RH's defaults.

A simple 

chown root.lire $LOGS
chmod 640 $LOGS

is enough. Logrotate will preserve the permissions when rotating the logs
and the defaults would only be reset if the log files had to be recreated 
(no log file present) which is not the case.

This is how I configured my system. We should probably document this.
(Advocate the creation of a log reader group) 

-- 
Francis J. Lacoste
francis at Contre.COM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/questions/attachments/20010702/d2f90625/attachment.bin