Re: Secure Apache Webserver

2006-10-30 Thread Joachim Schipper
On Sun, Oct 29, 2006 at 03:20:25PM +0100, Aiko Barz wrote:
 Hello,
 
 I already discussed this subject on the list. There were several
 possible solutions for this subject and I have chosen one, I would like
 to present now.
 
 The problem: I have several vhosts, which are used by several people.
 The Apache is running with $UID 67. Users can access the system by using
 scponly, which is jailed into /var/www. No problem here so far.
 This issue was, that all scripts must be readable or even writeable for
 the Apache Webserver. So one hacked page could damage other vhosts by
 writing some PHP code to access the other vhosts within /var/www.
 
 My solution:
 1. I made SuExec working within the chroot environment.
(http://www.openbsdsupport.org/ApacheSuexecChroot.html)
 2. I wrote a patch for suexec.c to handle *.php correctly.
(http://files.haeckser.net/haeckser.net/suexec.patch)
 3. I compiled PHP by my own with CGI-support and moved the binary into
the chroot.
 4. I removed mod_php and mod_perl and set the Apache directives User,
Group, AddHandler cgi-script and Options +ExecCGI.
 
 Now, every PHP-script has the permissions 700 and gets executed with its
 own $UID. I feel much better now. :)

I believe it is possible to set this up using FastCGI, which will
actually be (reasonably?) fast too.

Yes, I am a FastCGI fanboy.

Joachim



Re: Secure Apache Webserver

2006-10-30 Thread Marc Balmer

Joachim Schipper wrote:


I believe it is possible to set this up using FastCGI, which will
actually be (reasonably?) fast too.

Yes, I am a FastCGI fanboy.


I just spent the whole day setting up FastCGi using www/mod_fastcgi and 
www/fcgi.  I ended up with a server process, written C, that runs 
outside the apache chroot as a FastCGIExternalServer and Apache 
communicating with this through mod_fastcgi using an AF_UNIX socket.


The fastcgi server connects to a PostgreSQL database to do stuff, and 
yes, this setup is fucking fast.  And of course it does not have the 
security problems PHP has, the slowness of CGI nor the overhead of Zope...




Re: Secure Apache Webserver

2006-09-29 Thread Stuart Henderson
On 2006/09/29 11:16, Toni Mueller wrote:
 On Thu, 28.09.2006 at 09:47:51 -0400, James Strandboge [EMAIL PROTECTED] 
 wrote:
  Its extra work, but you could setup completely different chroots for
  each domain.  This way each domain is isolated and you can tailor each
  one to the user's needs.
 
 with this, you quickly run into the problem of consuming too many IP
 numbers, or do you have good argumentation against RIPE's objections?

not necessarily, you can put a reverse proxy in front.



Re: Secure Apache Webserver

2006-09-29 Thread Mark Bucciarelli
On Thu, Sep 28, 2006 at 05:48:26PM +0200, Joachim Schipper wrote:
 On Thu, Sep 28, 2006 at 12:52:41PM +0200, Joachim Schipper wrote:
  On Thu, Sep 28, 2006 at 10:55:30AM +0200, Aiko Barz wrote:
   The issue: If my users start to install a php-Filebrowser, they are
   able to access the other Webdirectories and could read config.php,
   because they are doing it with the permissions of the webserver.
   Write access would be possible as well, since some parts need to have
   write access.

  suExec + PHP is not feasible for many people, due to the high webserver
  load incurred; suPHP may be less problematic, or not.
 
 It appears, from a quick web search, that FastCGI allows one to give
 each user its own PHP instance.

Yes--wrap fastCGI daemons in suExec.  Each fastcgi process runs
with uid/gid of site owner.

Use dynamic servers and make 'em die out fast.  If a site is
busy, servers will stay resident and site is fast.  Low volume
sites are slow on first hit, as new server needs to spawn.  A
side benefit is that you can specify a different php.ini for each
vhost. 

Fix your umask for FTP server so other doesn't have read
permissions for newly uploaded files. Turn search bit off for
other users in as many directories in your vhost tree as
possible.

Expect to spend a couple days getting it right.  ;)

m



Re: Secure Apache Webserver

2006-09-28 Thread Henning Brauer
* Aiko Barz [EMAIL PROTECTED] [2006-09-28 10:59]:
 Hi *,
 
 I use OpenBSD+Apache+Chroot for my webservices. The users can access
 their vhosts by using scponly, which is chrooted into /var/www as
 well.
 /htdocs/www.example.net belongs to theuser:www and has the 
 permissions rwxr-x---. 
 
 The issue: If my users start to install a php-Filebrowser, they are
 able to access the other Webdirectories and could read config.php,
 because they are doing it with the permissions of the webserver.

php safe mode and basedir (set per vhost of course) can help there.

-- 
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg  Amsterdam



Re: Secure Apache Webserver

2006-09-28 Thread Joachim Schipper
On Thu, Sep 28, 2006 at 10:55:30AM +0200, Aiko Barz wrote:
 Hi *,
 
 I use OpenBSD+Apache+Chroot for my webservices. The users can access
 their vhosts by using scponly, which is chrooted into /var/www as
 well.
 /htdocs/www.example.net belongs to theuser:www and has the 
 permissions rwxr-x---. 
 
 The issue: If my users start to install a php-Filebrowser, they are
 able to access the other Webdirectories and could read config.php,
 because they are doing it with the permissions of the webserver.
 Write access would be possible as well, since some parts need to have
 write access.
 
 I started to patch suExec to make it handle *.php and to make it
 chroot-ready, but I wasn't successful so far. suPHP seems to have
 issues with 1.3.29 and ordering new IP-addressese for having multible 
 webserver intances seems to be difficult.

As Henning pointed out, PHP's open_basedir and friends can be useful,
although I would caution against believing they will actually work -
many problems have been discovered that would allow an attacker to
bypass open_basedir and uid/gid checks.

Notably, assuming one can put passwords and such in config.php is
probably not a good idea (Apache allows setting php_flags for this,
which can be made to be secure). It might be enough to keep people out
of each others' directories, though.

suExec + PHP is not feasible for many people, due to the high webserver
load incurred; suPHP may be less problematic, or not.

For now, I'm just running a dedicated server, so I've not yet
encountered this problem personally.

Joachim



Re: Secure Apache Webserver

2006-09-28 Thread Joachim Schipper
On Thu, Sep 28, 2006 at 12:52:41PM +0200, Joachim Schipper wrote:
 On Thu, Sep 28, 2006 at 10:55:30AM +0200, Aiko Barz wrote:
  Hi *,
  
  I use OpenBSD+Apache+Chroot for my webservices. The users can access
  their vhosts by using scponly, which is chrooted into /var/www as
  well.
  /htdocs/www.example.net belongs to theuser:www and has the 
  permissions rwxr-x---. 
  
  The issue: If my users start to install a php-Filebrowser, they are
  able to access the other Webdirectories and could read config.php,
  because they are doing it with the permissions of the webserver.
  Write access would be possible as well, since some parts need to have
  write access.
  
  I started to patch suExec to make it handle *.php and to make it
  chroot-ready, but I wasn't successful so far. suPHP seems to have
  issues with 1.3.29 and ordering new IP-addressese for having multible 
  webserver intances seems to be difficult.
 
 As Henning pointed out, PHP's open_basedir and friends can be useful,
 although I would caution against believing they will actually work -
 
 suExec + PHP is not feasible for many people, due to the high webserver
 load incurred; suPHP may be less problematic, or not.

Replying to myself to add another thought...

It appears, from a quick web search, that FastCGI allows one to give
each user its own PHP instance.

One final thought: it would be better to use /virtual, as the Apache
docs recommend, to prevent a misconfiguration giving access to
everything in /htdocs. Or, at least, create a /htdocs/index.html.

Joachim