So it looks like the new idea, though not perfect, seems to provide some value, at least under some circumstances. It also looks trivially to implement. Most effort is probably to tell people precisely why it is not a fully security guard. I'll see if I get this fully implemented next week if nobody objects. I guess it's not more than a day's worth.
Rainer > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:rsyslog- > [EMAIL PROTECTED] On Behalf Of Jan-Frode Myklebust > Sent: Friday, November 21, 2008 1:11 PM > To: [email protected] > Subject: Re: [rsyslog] rsyslogd security questions/comments > > 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. 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. > > > -jf > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
