On Nov 18, 2008, at 1:10 PM, [EMAIL PROTECTED] wrote:
> On Tue, 18 Nov 2008, Don Jackson wrote:
>
>> I had the following questions:
>>
>> Would it be possible (optionally) to have rsyslogd chroot to a
>> particular directory on startup?
>> That seems the safest. One could configure a disk partition for log
>> messages, configure rsyslogd to log there,
>
> chroot doesn't help. if you have rsyslog set to log to a seperate
> partition it can only fill that partition, but it can fill _all of
> that
> partition even if you chroot into a subdirectory on that partition.
Agree that file systems or partitions can get filled up no matter what
you do.
But it seems to me the safest thing to do is to enable rsyslog to be
configured to
use a specific file system on a dedicated partition, and then always
monitor that.
Clearly that is possible with rsyslog now, but chrooting would make
this even more restrictive/secure.
If the (r)syslog clients are also using rsyslog, then they could be
configured for reliable delivery,
and queue log msgs in the event the rsyslog "server" gets hosed,so one
you fixed your rsyslog server,
they would then be able to deliver their logs.
Seems like that would be the best overall approach.
>
>> and also chroot to a directory on that partition, so if the rsyslogd
>> process itself is compromised,
>> it can't do other damage.
>
> that gives you protection if you are receiving logs from the
> network, but
> if you are receiving logs from /dev/log (local logs) you can't go
> into a
> chroot effectivly
Protecting the "server" from attacks from networked clients seems like
a good idea.
To answer your later question, I use OpenBSD a lot.
Here is how the stock syslogd on OpenBSD provides a /dev/log for each
chrooted app:
NAME
syslogd - log systems messages
SYNOPSIS
syslogd [-dnu] [-a path] [-f config_file] [-m mark_interval]
[-p log_socket] [-s reporting_socket]
DESCRIPTION
syslogd reads and logs messages to the system console, log
files, pipes
to other programs, other machines and/or users as specified by
its con-
figuration file.
The options are as follows:
-a path
Specify a location where syslogd should place an
additional log
socket. Up to about 20 additional logging sockets can
be speci-
fied. The primary use for this is to place additional
log sock-
ets in /dev/log of various chroot filespaces.
So you can arrange for each chroot'ed application to have it's own
copy of /dev/log in its chroot.
It looks like syslogd on OpenBSD itself doesn't chroot. I am still
thinking it might be possible to do so (see below), but maybe I am
totally wrong about this.
>
>> There must be a way to have a daemon run as a non-root user, and also
>> to open ports < 1024.
>> This seems to be done all the time on *bsd machines:
>
> the POSIX standard still calls for ports < 1024 to require root to
> bind to
> them, different systems have different ways to be non-compliant with
> the
> standard and let you do so anyway. what OS are you using?
Sorry, I was not being clear nor accurate here.
What I meant to say was, OK, start up as root, open the resources you
need, and then chroot, both to change your userid to something that is
non-root ( user _rsyslog ?), and also
to put rsyslog into a restricted subset file system. Could you not
open up the network ports needed, and also /dev/log (for the benefit
of apps running on that machine that will
write there?) before the call to chroot?
If not, it looks like what syslogd on OpenBSD does is separate itself
into to processes, the main process runs as root, and then it spawns a
child that runs as user _syslogd,
it is this child process that listens to log sockets, while the parent
process gives the child access to write log files.
I'm just brainstorming here. Perhaps what I am thinking is not
possible.
Don
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
