On Fri, Nov 21, 2008 at 10:34, Jan-Frode Myklebust <[EMAIL PROTECTED]> wrote: > 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:
You are absolutely correct - an unbroken chroot() provides a security boundary that prevents the process[es] therein from accessing filesystem resources outside that boundary. Permissions on the directory structure at & below that point can provide additional restrictions (like noexec). > 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. Argue what you like, but your basis is flawed. You seem to forget that most exploits bring their own executable [shell]code with them and often operate purely in-memory. Therefore they don't strictly need external executables; the lack thereof is more of a nuisance than a roadblock. System designers _must_ assume that any successful remote attacker may access anything the application can, with the same permissions and executing arbitrary code - chroot or not. If the data you are logging is sufficiently sensitive that no client should be able to read the data and any possibility of their doing so would be catastrophic, you are going to have to either establish a one-way transport out of that syslog chroot() or limit your scope to the point that remote attackers are no longer a possibility. RB _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
