You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rod Roark <ro...@sunsetsystems.com> on 2001/10/25 13:02:48 UTC
Virtual hosting: comments requested
OK, time for a break from the normal routine. :-)
This concerns "name based" virtual hosting. I.e., with just one IP
address.
The problem is how do you give your users access to PHP, servlets,
CGI, etc. and still keep them somewhat secure from each other's
potential mischief. Suexec is not enough, and multiple httpd
instances are not really an answer because then only one user gets
port 80.
I did come up with a possible solution. However I'm not sure if it's
complete garbage, mildly useful, or really interesting. That's why
I'm posting here.
My "virtual hosts" section of httpd.conf looks something like this:
NameVirtualHost *
<VirtualHost *>
ServerName www.somename.com
DocumentRoot /opt/www/users/somename_ThisIsASecret
...
</VirtualHost>
<VirtualHost *>
ServerName www.anothername.com
DocumentRoot /opt/www/users/anothername_ThisIsAnotherSecret
...
</VirtualHost>
...
Then, /opt/www/users looks like this:
drwx--x--x root root .
drwxrwx--- some apache somename_ThisIsASecret
drwxrwx--- another apache anothername_ThisIsAnotherSecret
You get the idea. Nobody can list the contents of /opt/www/users,
but users can get into their own directory if they know its name.
Also httpd.conf is set to be readable only by root. It turns out
this works because apache starts up with root permissions.
I think the main problem here is the potential for people poking
around inside apache to get documentroot names... but I don't know
much about that.
Comments? TIA for your wisdom....
-- Rod
Re: Virtual hosting: comments requested
Posted by Rod Roark <ro...@sunsetsystems.com>.
Thanks Cliff... that was the kind of feedback I was looking for.
Guess I'll have to wait for 2.0.
BTW you guys are the greatest!
-- Rod
On Thursday 25 October 2001 06:21 pm, Cliff Woolley wrote:
> On Thu, 25 Oct 2001, Rod Roark wrote:
> > Um, how? It's clear that all scripts will run as user apache,
> > but the whole point is that if you don't know the other user's
> > documentroot name
>
> Well, I'd kind of missed that you were counting on the 711 directory
> permissions. But still...
>
> > then you can't formulate a malicious request.
>
> Sure you can. There's an ap_document_root() function, all you need
> is the server_rec for that vhost. The list of server_rec's is
> static to the core, but if you tried hard enough, I bet you could
> find a way to get at it.
>
> For example, while I haven't actually tried this, I just poked
> around in http_vhost.c and it looks like you can change r->hostname
> to the host you're interested in, then call
> ap_update_vhost_from_headers(r) and then call
> ap_document_root(r->server) and you've got the docroot.
>
> Even if this is broken for some reason (like I say, I didn't
> actually try it), there's most likely some other way to do it. This
> is security through obscurity at best, unfortunately. :-/
>
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
Re: Virtual hosting: comments requested
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 25 Oct 2001, Rod Roark wrote:
> Um, how? It's clear that all scripts will run as user apache,
> but the whole point is that if you don't know the other user's
> documentroot name
Well, I'd kind of missed that you were counting on the 711 directory
permissions. But still...
> then you can't formulate a malicious request.
Sure you can. There's an ap_document_root() function, all you need is the
server_rec for that vhost. The list of server_rec's is static to the
core, but if you tried hard enough, I bet you could find a way to get at
it.
For example, while I haven't actually tried this, I just poked around in
http_vhost.c and it looks like you can change r->hostname to the host
you're interested in, then call ap_update_vhost_from_headers(r) and then
call ap_document_root(r->server) and you've got the docroot.
Even if this is broken for some reason (like I say, I didn't actually try
it), there's most likely some other way to do it. This is security
through obscurity at best, unfortunately. :-/
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: Virtual hosting: comments requested
Posted by Rod Roark <ro...@sunsetsystems.com>.
Cliff Woolley said:
> On Thu, 25 Oct 2001, Rod Roark wrote:
>
>> I did come up with a possible solution. However I'm not sure if it's complete
>> garbage, mildly useful, or really interesting. That's why I'm posting here.
>>
>> Then, /opt/www/users looks like this:
>>
>> drwx--x--x root root .
>> drwxrwx--- some apache somename_ThisIsASecret
>> drwxrwx--- another apache anothername_ThisIsAnotherSecret
>>
>> You get the idea. Nobody can list the contents of /opt/www/users, but users can get
>> into their own directory if they know its name.
>
>
> This does of course restrict them when they're logged on to your machine as
> themselves... the real problem in all of this, though, is that their CGI scripts and
> PHP documents and so on all run as the apache user, and the apache user has rights to
> all of them, meaning that they all can get access to each others' files by simply
> telling the webserver to do it for them.
Um, how? It's clear that all scripts will run as user apache,
but the whole point is that if you don't know the other user's
documentroot name then you can't formulate a malicious request.
Or is there an API that gives you this information?
> SuExec fixes this for CGI, but not for PHP
> and so on. The real solution will come with Apache 2.0 as the "perchild MPM" which
> allows separate Apache child processes to run under different UIDs. Each child only
> handles those requests that are for the virtual hosts assigned to it, and it hands
> off requests for other vhosts to the other children as necessary. This is better
> than the approach of totally separate instances of httpd since, as you mention, in
> the totally separate scenario only one can be running on port 80 for a given IP
> address.
Very good news!
> --Cliff
>
> --------------------------------------------------------------
> Cliff Woolley
> cliffwoolley@yahoo.com
> Charlottesville, VA
-- Rod
Re: Virtual hosting: comments requested
Posted by Cliff Woolley <cl...@yahoo.com>.
On Thu, 25 Oct 2001, Rod Roark wrote:
> I did come up with a possible solution. However I'm not sure if it's
> complete garbage, mildly useful, or really interesting. That's why
> I'm posting here.
>
> Then, /opt/www/users looks like this:
>
> drwx--x--x root root .
> drwxrwx--- some apache somename_ThisIsASecret
> drwxrwx--- another apache anothername_ThisIsAnotherSecret
>
> You get the idea. Nobody can list the contents of /opt/www/users,
> but users can get into their own directory if they know its name.
This does of course restrict them when they're logged on to your machine
as themselves... the real problem in all of this, though, is that their
CGI scripts and PHP documents and so on all run as the apache user, and
the apache user has rights to all of them, meaning that they all can get
access to each others' files by simply telling the webserver to do it for
them. SuExec fixes this for CGI, but not for PHP and so on. The real
solution will come with Apache 2.0 as the "perchild MPM" which allows
separate Apache child processes to run under different UIDs. Each child
only handles those requests that are for the virtual hosts assigned to it,
and it hands off requests for other vhosts to the other children as
necessary. This is better than the approach of totally separate instances
of httpd since, as you mention, in the totally separate scenario only one
can be running on port 80 for a given IP address.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA