> I would say that chroot jails do not prevent exploitation > of buffer overflow vulnerabilities correct > AND they do not prevent > the aftermath of such exploitation either. They *can* limit the aftermath. It depends what you are trying to defend against. > For example, a chroot jail does not prevent execution of > systems calls from within the vulnerable program address > space therefore the exploit code can easily break out of the chroot > jail If you have root priviledges then yes - but how do you get root priviledges? Your chroot jail shouldn't contain any suid binaries and your service shouldn't run as root. > or perform > socket calls > to proxy attacks to other hosts or download more complex > exploitation code from the attackers box or a wide range of other > interesting things. Indeed. > If you rely on chroot jails to mitigate the risk of exploitation of a > vulnerable program you are wasting your time, it would be > better to invest your time in making sure your program doesnt > have holes in the first place. Correctly configured chroot jails limit the damage an attacker can do. If nothing else a chroot will slow them down, giving you and your IDS longer to detected them and sort it out. Chroots are fairly easy to deploy so can be used as a defence in depth tool. I think my program is secure (no audit is guaranteed to find all bugs) but just in case I'll place some firewalls about the place, use capabilities or similar where the OS supports them, run the process under a low priveledged user id and put it in a chroot. Staurt
This archive was generated by hypermail 2b30 : Fri May 24 2002 - 17:07:28 PDT