On 2008-11-21, RB <[EMAIL PROTECTED]> wrote:
> 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.
I think the chroot() limits the possibility of:
- executing anything outside the chroot (f.ex. /bin/sh)
- write a new file, and execute it (noexec on the chroot mountpoint)
- overwrite something outside the chroot. I'm an itsy bit worried that
something like this:
$template PerAppLogs,"/var/log/apps/%programname%.log"
*.* -?PerAppLogs
could be tricked to write to unexpected places if you mess with
%programname%, or other similar variables that the sender has complete
controle over.
so I would argue that my sensitive syslogged data is more secure in a
chroot environment where there are no other executables, than on a non-
chroot environment.
-jf
--
To know recursion, you must first know recursion.
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com
