On Sat, Nov 22, 2008 at 04:17, Jan-Frode Myklebust <[EMAIL PROTECTED]> wrote: > Did you see the comment from Rainer about the secpath-replace property? > I think that proves my basis is not flawed. The chroot here protects > against code flaws, or configuration flaws that could otherwise give > attacker the possibility of overwriting system files.
I most certainly did, but all the secpath-replace property protects against is an administrator foolishly trusting unvalidated data from a remote host to generate file paths. Chroot does not protect against code flaws, full stop. That is the continuing flaw in your argument. Chroot only prevents code flaws from affecting anything _outside_ of the chroot environment. > Also you pointing at "most exploits bring their own executable .. operate > purely in-memory" argument is flawed when I'm arguing for chroot being > *more* secure. Not 100% secure against all flaws, but *more* secure than > a non-chrooted process. You mistake what I am arguing - there is no question that chroot() helps protect the host system's files. What it does _not_ protect against is abuse of anything within the chroot(). Your statement was: > so I would argue that my sensitive syslogged data is more secure in a > chroot environment If your log data is being stored inside that chroot, you are utterly wrong. Please actually understand what chroot() does before you continue making wild, unfounded statements. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
