Fastcgi or apache-mpm-itk?

[Paul van der Vlis]

Hello,

I would like to install Apache for shared hosting. I would like also a
form of secure PHP.

I like to use Debian packages for security-support. There are no
packages for mpm-peruser and mod-ruid so I don't want them.
Suphp and php5-cgi are slow, I've heard.

Stays suexec/fastcgi like here:
http://www.cosmocode.de/en/blogs/gohr/20070516093908/
http://packages.debian.org/etch/libapache2-mod-fastcgi  (nonfree!)

And apache2-mpm-itk:
http://blog.stuartherbert.com/php/2008/04/19/using-mpm-itk-to-secure-a-shared-server/
http://packages.debian.org/etch/apache2-mpm-itk

What would you choose?

With regards,
Paul van der Vlis.



--
http://www.vandervlis.nl/


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Craig Sanders]

On Tue, Jun 03, 2008 at 05:08:09PM +0200, Paul van der Vlis wrote:

> I would like to install Apache for shared hosting. I would like also a
> form of secure PHP.
>
> I like to use Debian packages for security-support. There are no
> packages for mpm-peruser and mod-ruid so I don't want them.
> Suphp and php5-cgi are slow, I've heard.
>
> Stays suexec/fastcgi like here:
> http://www.cosmocode.de/en/blogs/gohr/20070516093908/
> http://packages.debian.org/etch/libapache2-mod-fastcgi  (nonfree!)
>
> And apache2-mpm-itk:
> http://blog.stuartherbert.com/php/2008/04/19/using-mpm-itk-to-secure-a-shared-server/
> http://packages.debian.org/etch/apache2-mpm-itk
>
> What would you choose?

i use apache2-mpm-itk, partly because i think suexec is too inflexible
to bother with. if you want to do things *EXACTLY* as has been
hard-coded into it at compile time, it's OK. any minor variation and it
just won't do it, and can't be made to.  I've never liked suexec, even
before i found apache2-mpm-itk, i used cgiwrap as a far more flexible
alternative.

i use it with libapache2-mod-php5 (w/ php5-suhosin) and it works great.

i also use it (on the same servers as mod-php5) with libapache2-mod-speedycgi
for persistent perl CGI scripts - in a vhosting environment, that's MUCH
safer than mod_perl.

(one thing that works extremely well as an alternative to mod_perl or
as a perl alternative to PHP is the combination of apache2-mpm-itk,
libapache2-mod-speedycgi, and libhtml-mason-perl aka HTML::Mason. perl
embedded in html rather than PHP)

anyway, just set up apache2-mpm-itk and pretty much forget it.
essentially no maintainence required. each vhost runs as it's own user,
so no more world-writable or www-data writable files, no need to worry
about one vhost's scripts being able to read (or write!) another vhost's
private files.

the one (very minor) hassle with it is that because it's not an official
apache2 mpm (it's a fork of apache2-mpm-prefork), it lags behind the
other apache packages, usually by a few days. if you're sticking with
stable, this won't be a problem at all....but if you're tracking testing
or unstable, you need to be careful about upgrades, mark apache2-mpm-itk
as held so it doesn't get auto-removed, and upgrade it manually when you
know it is available.

craig

--
craig sanders <cas@...>

BOFH excuse #13:

we're waiting for [the phone company] to fix that line


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[norbert_schuetz]

Hi folks.

Is there, in addition to itk, any solution for chrooting webspace
environments to make sure any (php) user would not have access
outside her htdocs directory?
An additonal plus woul be that you could shift around webspace
directories (read: failover ;-) without running into trouble because
stupid PHP scripts use hard-coded paths like say
/var/www/customerid/mydomain/htdocs/ somewhere?

TIA,
Norbert


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[norbert_schuetz]

Boris Pavlov wrote:

Thx for the reply Boris

>> Is there, in addition to itk, any solution for chrooting webspace
>> environments to make sure any (php) user would not have access
>> outside her htdocs directory?
>> An additonal plus woul be that you could shift around webspace
>> directories (read: failover ;-) without running into trouble because
>> stupid PHP scripts use hard-coded paths like say
>> /var/www/customerid/mydomain/htdocs/ somewhere?

> 1)the only 1000% secure way to separate two things is to separate them
> physically. but you may try grsec and apache chroots for something real,
> w/o complete virtualization.

What exactly do you mean with "apache chroots"? Is there any
particular Apache feature I'm missing? How exactly does that work
with Apache - wouldn't Apache/PHP miss the (system wide) dirs like
/usr/lib/php5 and libraries etc.?


> 2)look at mount -o bind /dir /otherdir

This would maybe help mapping in directories in failover state from
somewhere else but still, if customers use absolute paths like
/var/www/customerid/mydomain/htdocs/... I still might need to "fake"
the whole structure.
I'd prefer a way to let each customer (her PHP script, that is) see
only /www (on a per vhost basis) as it would be with chroot.

Cheers,
Norbert


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lionel Elie Mamane-2]

On Tue, Jun 03, 2008 at 05:08:09PM +0200, Paul van der Vlis wrote:

> I would like to install Apache for shared hosting. I would like also
> a form of secure PHP.

> I like to use Debian packages for security-support. There are no
> packages for mpm-peruser and mod-ruid so I don't want them.  Suphp
> and php5-cgi are slow, I've heard.

> What would you choose?

I use Apache as a reverse proxy front-end and a backend of lighttpd
(with mod_extforward activated) executing the PHP code; I run the PHP
just as CGIs (no speed needs), but lighttpd supports the FastCGI
interface, so you can use that to save the fork/exec overhead. Each
user has his own backend running under his UID (actually, a dedicated
UID different from his that he can sudo to or with group memberships
and filessytem ACLs setup so that things work); possibly that won't
scale enough for you.

This solution sometimes requires fixing the PHP code to use the right
hostname in self-referencing links; some PHP apps look at the wrong
place and construct backend URLs instead of front-end URLs. (I don't
remember out of the top of my head, but it is something like
SERVER_NAME vs HTTP_HOST.) Many apps use the wrong source, but have a
setting that overrides their wrong detection statically; it is often
easier to set this rather than fix the wrong detection logic.

--
Lionel


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Kim Christensen-8]

Norbert Schuetz wrote:

> Hi folks.
>
> Is there, in addition to itk, any solution for chrooting webspace
> environments to make sure any (php) user would not have access
> outside her htdocs directory?
> An additonal plus woul be that you could shift around webspace
> directories (read: failover ;-) without running into trouble because
> stupid PHP scripts use hard-coded paths like say
> /var/www/customerid/mydomain/htdocs/ somewhere?

You could always use open_basedir() to restrict file system operations.

http://www.php.net/features.safe-mode

That way you can make sure that your users won't be able to access files
outside of their home directory, but not forcing them to rewrite their
scripts because of a chroot().

However, this has been removed in PHP 6...

Best regards,
Kim
--
|_|O|_|  Kim Christensen
|_|_|O|  Public key: http://rac.nu/kchr.asc
|O|O|O|  Web home:   http://blog.technopragmatics.org
--------------------------------------------------------
() ascii ribbon campain - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[norbert_schuetz]

Hi Kim,

> You could always use open_basedir() to restrict file system operations.
>
> http://www.php.net/features.safe-mode
>
> That way you can make sure that your users won't be able to access files
> outside of their home directory, but not forcing them to rewrite their
> scripts because of a chroot().
>
> However, this has been removed in PHP 6...

Thx for your reply but I guess you didn't get the point I was aiming
at: The idea is indeed not to force customers to rewrite their
code  -> in the case we decide to rearange the directory structure
for whatever reasons (failover could be one) . With the (badly
broken) safemode and open_basedir this is what you exactly do *not*
get. All you get is problems all over the place (with so-called
safemode I remember not being able to write files in
/var/www/domain/htdocs/ with while useing '.' worked fine although
both pointed to the same dir... but this might not be the place to
discuss PHP problems ;-)

I was looking for a solution to have the users see, say, '/www' as
their document root, mapping this to some diretory of my choice.
Mainly not as a security measure but for more system administration
flexibility.

Thx anyway,
Norbert


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Christian Kujau-3]

On Tue, 10 Jun 2008, kchr-list-debian@... wrote:
> However, this has been removed in PHP 6...

got a pointer? The closest thing I've found was
http://wiki.php.net/todo/php60, where open_basedir is merely cleaned up,
but not removed...

C.
--
BOFH excuse #409:

The vulcan-death-grip ping has been applied.


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Stephen Gran]

This one time, at band camp, Christian Kujau said:
> On Tue, 10 Jun 2008, kchr-list-debian@... wrote:
> >However, this has been removed in PHP 6...
>
> got a pointer? The closest thing I've found was
> http://wiki.php.net/todo/php60, where open_basedir is merely cleaned up,
> but not removed...

open_basedir is discussed at:
http://uk3.php.net/manual/en/features.safe-mode.php#ini.open-basedir

Note the top of the page which tells you "Safe Mode was removed in PHP
6.0.0."
--
 -----------------------------------------------------------------
|   ,''`.                                            Stephen Gran |
|  : :' :                                        sgran@... |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |
 -----------------------------------------------------------------

[Kim Christensen-8]

norbert_schuetz@... wrote:

> Hi Kim,
>
>> You could always use open_basedir() to restrict file system operations.
>>
>> http://www.php.net/features.safe-mode
>>
>> That way you can make sure that your users won't be able to access files
>> outside of their home directory, but not forcing them to rewrite their
>> scripts because of a chroot().
>>
>> However, this has been removed in PHP 6...
>
> Thx for your reply but I guess you didn't get the point I was aiming
> at:

You are correct -- I blame it on caffeine deprivation... ;-)

> The idea is indeed not to force customers to rewrite their
> code  -> in the case we decide to rearange the directory structure
> for whatever reasons (failover could be one) . With the (badly
> broken) safemode and open_basedir this is what you exactly do *not*
> get. All you get is problems all over the place (with so-called
> safemode I remember not being able to write files in
> /var/www/domain/htdocs/ with while useing '.' worked fine although
> both pointed to the same dir... but this might not be the place to
> discuss PHP problems ;-)
>
> I was looking for a solution to have the users see, say, '/www' as
> their document root, mapping this to some diretory of my choice.
> Mainly not as a security measure but for more system administration
> flexibility.

There is a way to do what you're asking for:

http://www.seaoffire.net/fcgi-faq.html#I-E

By letting SuExec chroot() into "/var/www/domain" when it spawns a new
process, your users' PHP scripts would see /htdocs as its web root
(physical location: /var/www/domain/htdocs) and nothing outside of its
root directory.

Since the chroot() is only done by SuExec when running scripts, you
won't have to put Apache libs in your jail. I'm unsure about PHP though.

Also remember to use an ftpd with chroot() support, like pureftpd or vsftpd.

Best regards,
Kim
--
|_|O|_|  Kim Christensen
|_|_|O|  Public key: http://rac.nu/kchr.asc
|O|O|O|  Web home:   http://blog.technopragmatics.org
--------------------------------------------------------
() ascii ribbon campain - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments


--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[norbert_schuetz]

Hi Kim

>> I was looking for a solution to have the users see, say, '/www' as
>> their document root, mapping this to some diretory of my choice.
>> Mainly not as a security measure but for more system administration
>> flexibility.
>
> There is a way to do what you're asking for:
>
> http://www.seaoffire.net/fcgi-faq.html#I-E
>
> By letting SuExec chroot() into "/var/www/domain" when it spawns a new
> process, your users' PHP scripts would see /htdocs as its web root
> (physical location: /var/www/domain/htdocs) and nothing outside of its
> root directory.
>
> Since the chroot() is only done by SuExec when running scripts, you
> won't have to put Apache libs in your jail. I'm unsure about PHP though.

| FastCGI provides for a wrapper that will execute
| the interpreter, in this case PHP

I was hoping for a solution for mod_php, since php-cgi is
lacking some important features (http-auth, for example)
and setting up a complete chroot environment is quiet a
pain as you usually end up not beeing able tu use Debian
packages at all.

Still I might check again if we could live with the
cgi-drawbacks.


> Also remember to use an ftpd with chroot() support, like pureftpd or vsftpd.

Yes, apart from the unusual way to configure it we really like pureftpd
(mysql). It has been serving all webhosting customers for a long time
now without any problems.

Cheers,
Norbert



--
To UNSUBSCRIBE, email to debian-isp-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...