On Fri, 21 Nov 2008, Jan-Frode Myklebust wrote: > For my usage, I need two modes of operation for syslog daemons. > > 1 - local syslog. Requires privileges to on local devices (/dev/log, > /dev/klogd or similar), write to local log-files, and send to > remote log server. > > 2 - central log server. Only listen on the needed network ports > (514/udp/tcp), and write to local log files (possibly also send > to other remote log servers). > > For #1 I think it's OK not being able to chroot, keep more privileges, > etc., as the attacks against it will mostly be from local processes. > > #2 needs to be *very* openly available on the network ports, since all > my servers needs to send logs to it. #2 will also be holding a lot more > sensitive data than #1, so I think this server needs to be protected as > much as possible.
just pointing out that on this central server the data will be in the same place as the daemon listening to the network, and accessable to that daemon, so chrooting, dropping privilages, etc won't protect the data that gets logged (it will allow you to protect other data that lives on the server, just not log data) well, you could do something where rsyslog writes the file in the chroot, and when it rolls the file something outside the chroot picks it up and moves it elsewhere, but that's starting to get a little extreme. > If chroot'ing, or dropping privileges prevents it from > reading from local /proc og /dev, I think that wouldn't matter much. One > could always run two instances on these few central servers, i.e. #1 > sending to #2. correct. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
