6,534
edits
Changes
m
More posts == The problem == One of the problems with shared web hosting (i.e. different people with each his/her own webpages) is that modern script languages such as PHP, Python, or Perl are too powerful. For example take the following PHP script: <pre><?php function get_content($filename) { $handle = fopen($filename, 'r'); echo fread($handle, filesize($filename)); fclose($handle);} get_content('/home/ppuk34/www/forum/config.inc.php'); ?></pre> With PHP you could use open_basedir to prevent this quality, but there are more ways. For example [http://mgeisler.net/php-shell/ PHP Shell], a script that is [http://mgeisler.net/downloads/phpshell/SECURITY often mis-used] by people with not-so-good intentions. Or think about the [http://www.f-secure.com/v-descs/santy_a.shtml Santy-worm] which mis-used phpBB. Not Again there is a solution in the usual c***form of safe_mode, pelsaebut lots of PHP scripts break if you enable this. For Python, Perl, or CGI-scripts there are no easy ways and you have to use wrappers or other tricks to chroot these.
Protected "Shared webhosting": Excessive spamming ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))
{{roughstub}}
== The solution ==
[[Image:Shared hosting1.png|345px|right|The OpenVZ way of shared webhosting]]
You can waste hours of time in securing all the possible things you don't want in your shared [http://webhostingvergleich24.info webhosting] environment. And unless you are very familiar with all the things modern scripting languages can do, you probably miss dozens of alternative routes. In this process you frustrate your clients, because security always means that legitimate things break. As a side effect of your hard work, you can waste hours of extra time in educating your users. But in the end most users don't care about security, unless they are themselves victims of a compromised host. Learning the hard way is by far the most effective method. One possible solution is dedicated webhosting, but most users don't have the experience to maintain a server or it is way to expensive for them.
The main problem with shared webhosting is that by its very nature all files which are served through the web are public. Apache for example uses only one account to read all files. As said, you can use tricks with CGI wrappers to execute the scripting languages under its own credentials. However this kind of security depends on the wrappers ability to securely separate the users. We all know that if this is broken — and most often it will be broken — the result is a higher clearance on the underlying filesystem. For most systems you need more than one wrapper, so the number of possible security problems grow. The ultimate user separation is in the kernel and you can view the modifications OpenVZ has done in this light. Instead of CGI wrappers we go one step higher and give every user its own minimal server. In the rest of this article we describe how shared webhosting with OpenVZ could be implemented.
