From: Justin M Kuntz (jkuntz_at_prominic.com)
Date: Wed 08 May 2002 - 18:51:44 BST
Johan --
Your work on securing Apache + PHP etc. could definitely be beneficial in
the context of further securing Apache from root exploits by putting the
engine inside a vserver. See
http://www.solucorp.qc.ca/mlist/index.hc?list=vserver to subscribe to the
list - I think you'll find it very beneficial.
Rod --
I think this is related to your Cookbook Vservers concept. Lets work on
this together. Can you send me a draft of what you've got so far or post
it somewhere so we can all begin to look at it?
Vlad --
Your post here is especially relevant to vserver in a hosted environment:
http://vserver.vlad.net/list/0135.html
I think many of us are interested in vserver because it helps our web
hosting operations be more secure, scalable, reliable, etc. But rather
than each of us re-inventing the wheel about vserver + apache + mysql +
standard web hosting security framework, I do think we need to help Jack
and the vserver development group by documenting some best practices. Jack
and the other real wizards on the mailing list are busy figuring out
complex kernel things... so hopefully we can help the vserver effort with
sharing our use of it in production environments.
vserver has a ton of power. What we need to do is combine its raw power
with some boiler-plate ways to help it manage applications. Look at what
the commercial offerings have like http://www.sphera.com and
http://www.ensim.com ... those places have figured out how to best allow
Apache + MySQL + PHP + etc. to be safely segmented from one another on a
per-user basis. Lets do the same thing and wrapper each one in vservers.
I see two basic approaches for web hosting security with vservers. I will
call them Shared Apache and Partitioned Apache, defined as follows:
* Partitioned Apache is an instance of Apache (in its own vserver) with all
the modules that someone wants bound directly into it, such as mod_perl,
mod_php, etc. From what I understand, if mod_php is loaded into an Apache
server, any PHP script executed is going to run with the same privs as the
Apache base server. Same thing with Perl, etc. This is a problem in the
case that more than one untrusted user is going to be using the same Apache
server. The solution of course is to give each untrusted user their own
Apache vserver. However, this means that each customer must be assigned
their own IP address and that multiple virtual domains (for different
customers) can not be used to share an IP address... naturally, IPs are
hard to come by so this is a problem. So the idea is that customers who
want to pay for extra security, reliability, and configuration capabilities
of their own Apache Partition will pay a premium. But most customers who
are primarily concerned with cost will want a Shared Apache.
* Shared Apache is an instance of Apache (in its own vserver), but with no
security-hole modules compiled in, and multiple untrusted customers each
given their own home directory for cgi-bin, etc. Shared Apache is
basically Partitioned Apache but meant to be shared among many untrusted,
unrelated customers. The key to security in a Shared Apache environment is
suexec or cgiwrap must be used to wrapper any programmable logic done by
each untrusted user. Really most "semi-safe" hosting environments right
now are using this basic model of an suexec/cgiwrap with an Apache server
running lots of virtual domains to host many different customers on the
same Apache engine, and typically sharing the same IP address. This is
great in terms of resource sharing for IPs, memory, and processing time
since only one Apache instance is used. But what if that Apache instance
gets hacked? That's why it should be wrappered in a vserver of course.
Frankly I've looked into both Ensim and Sphera. Both are extremely
expensive, and they are closed proprietary technology that requires pretty
much full adoption of their automation systems. The core technology at
work in Ensim may be more polished than vserver right now... but certainly
vserver is so far along that it has proven its potential already for
becoming part of the core Linux kernel down the road. What vserver needs
to become polished for web hosting is:
1) Ensim-like resource guarantees. This means having minimum resource
guarantees, but allow for burstability when technically feasible in terms
of CPU and bandwidth. There should be quotas on disk space and memory
usage, as well as possibly file descriptors... maybe we can think of other
resources which are generally limited and can cause a crash if someone
exhausts them. I know ulimit can do a lot of this on a per-process basis
but we need to make it on a per-vserver basis.
2) Sphera-like application support inside Apache. Sphera does a GREAT job
of having an integrated system for everything from Tomcat to MySQL. I'm
not proposing we go that far with documenting this stuff, but I think the
more we can combine what is needed by web-hosters and ISPs within Rod's
idea of cookbook vservers, the more attractive vserver will look.
Here is a great article on these other web hosting systems - it's short but
hits the major points of resource isolation:
http://hosting.developersnetwork.com/Articles/Articles.asp?Article=290
Let me know your thoughts...
Justin