If you things you truly need to keep secure from another user (credit card data, health information) please do not use virtualization. Like chroots, it has it's own problems. VMWare had a exploit a while back [1] and any kernel exploit that gets you to ring-zero should get you through Virtuozzo/OpenVZ. The best way to enforce security, and what is required by things like PCI is a separate physical computer behind a firewall.
The most secure computer is of course, completely disconnected from any power source or network or any other input, powered off, covered by lead shielding with round the clock guards. And even that isn't 100% secure. Keep in mind time vs. security. If all you can do feasibly is openvz, then that is still one step above chroot'ing. [1] http://www.cupfighter.net/index.php/2009/07/blackhat-cloudburst-vmware-guest-to-host-escape/ Thanks, Will On Tue, 2009-10-20 at 18:36 +0200, Roland Tapken wrote: > Hi, > > > why fiddling with permissions and groups where you can isolate > > _everything_ wasting some disk space? > > AFAIK, chrooting is the way that big hosting providers uses. this also > > lets you limit the commands a user can execute, while root can still use > > every binary. > > I know, I've used this method a few years ago on my own server. But chroot > has > some disadvantages. Firstly, you have to copy all required bins, libs and > dependencies(!) after each update. Of course, this can be done by a script, > but nevertheless you can't be sure that every single user site still works if > you don't clone all libs and bins (for example, I had the problem that > ImageMagick released something into a separate binary which was suddenly > missing because it wasn't listed by ldd). > > Next, a user might be able to upload and execute his own binary. To prevent > this, you have to disable chown functions completely or bind the > user-writable > tree to a partition mounted with noexec option. > > And finally, it's possible to break out from a chroot jail ([1]). > > Conclusion: It's very, very hard to realize a real secure chroot jail without > making it unusable. If you want to have real separated processes per user, > buy > a lot of ram and use a virtual maschine (OpenVZ should do so). If you just > want to hide your customer's from each other, use anonymous user names or the > chgrp method. > > [1] http://www.bpfh.net/simes/computing/chroot-break.html > > Viele Grüße, > Roland Tapken _______________________________________________ suPHP mailing list [email protected] https://lists.marsching.com/mailman/listinfo/suphp
