On Fri, Nov 21, 2008 at 07:31, <[EMAIL PROTECTED]> wrote: > 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)
As is the same with all chrooted processes - the chroot model prevents untrusted processes from messing with each other's candy, not their own. If anyone that runs a chroot thinks otherwise, they're sorely mistaken. It's why web servers are often chrooted with no write access: the only writing they can do is back through specific ports (database, syslog, memcache, etc.) > 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. I absolutely agree that approach is foolish - better to give the process no write permissions at all and have it either log to a database (INSERT-only user) or run a two-layered approach wherein the chrooted log server passes the [scrubbed] logs it receives back over a pipe or to a secondary syslog service. Crash/subvert the front layer, you have little place to go. RB _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
