In data martedì 20 ottobre 2009 18:36:41, Roland Tapken ha scritto: > 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).
Yes, there is a script that does all the magic. The "missing library problem" could be easily avoided if you don't apply untested updates on production platforms. A test server will save lots of headaches ;) > 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. Yep > And finally, it's possible to break out from a chroot jail ([1]). That page was last edited in 2002. It needs SUID binaries INSIDE the chroot to work. And some bug that lets user gain root privileges before escaping. Ensuring there is no SUID binary will throw that exploit right to /dev/null > 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. An "anonymous" user that does a "chmod 777 ~" will make his home directory accessible from the whole world. Another "anonymous" user could write malicious php script in his webroot (we are on suphp mailing list, so we talk about webservers) Is that more secure than a chroot? -- Giuseppe Iannello System administrator _______________________________________________ suPHP mailing list [email protected] https://lists.marsching.com/mailman/listinfo/suphp
