Question: Is there a similar security model for apache that would allow
credentials from a user to run a virtual website and access files only
for a specific virtual site.
Yes and no, depending on what your requirements are and which server
you are using (i.e. Apache 1.x or 2.x).
In the Apache 1.x branch there is no such feature, but there exists
a hybrid model which many people are happy with. In the hybrid model
Apache normally runs as single non-root user (e.g. httpd) and
switches to the web site user to execute CGI scripts.
This is the so-called suEXEC feature. A third party utility called
cgiwrap can be used (replacing suEXEC) to isolate scripts into their
own isolated filesystems (chroot).
The problem with this method is that it has a significant impact
on performance. CGI scripts are created and destroyed on every hit
and this introduces a large overhead. Another problem is that suEXEC
only works for CGI scripts and does not work for modules. Since these
utilities rely on Unix-specific features they can't be used on
non-Unix systems.
Better performance may be achieved with the use of the FastCGI
protocol. It allows scripts to persist, executing many requests
before shutting down. But the problem here is that the scripts
must have the FastCGI support built-in (which may or may not
be complicated depending on what you want to use).
The Apache 2.x branch was intended to have the functionality you
inquire about since the very beginning, with the per-child
processing module. Unfortunately, the module never achieved
stability and is likely to be removed from the server soon (before
the 2.2 release, which is likely to happen in November). But there
is a separate effort to implement the same functionality with the
metuxmpm module (http://www.metux.de/mpm). There is also some
talk for metuxmpm to become part of the official distribution. This
module appears to work although it is not 100% there yet (BTW, I
haven't used it myself).
With metuxmpm, all of the processing for a web site is performed
by a web site user, both file access and script execution, making
this approach a very secure one indeed.
Naturally, Apache 2.x supports all of the 1.x approaches too.
Finally, there is a third option, applicable equally to both
Apache branches, where you can have each web site run its own
Apache instance. This is easy to do if you have one IP address
per web site available. You would have to assign a separate IP
address to a web site to support SSL anyway so this is not
a big deal.
If you have only one IP address to play with then you can
configure one Apache instance (let's call it a master) to run as
a reverse proxy, forwarding requests to other Apache instances.
For each web site you will have a separate Apache installation
(which runs on a higher port, and is not accessible directly)
configured to run as a separate web user.
This third option is what I would recommend at the moment as
a stable and performance-efficient solution. You get the security
you need. On top of that, each web site has full access to (its)
Apache configuration and is free to use it as they are pleased.
Of course, there is a drawback. This approach is not feasible where
there are many (e.g. hundreds) web sites to be run this way, since
there must exist at least two Apache processes per web site.
--
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]
