mike503 at gmail.com
Sat Apr 12 01:21:04 MSD 2008
If we're talking PHP level, i find it best to run individual fastcgi
pools per user.
php-fpm makes this a breeze now.
if their scripts get exploited, the only files that can be modified
are their own. it doesn't account for any PHP exploits though, and the
scripts can still be exploited and non-root activities can occur (i.e.
zombie bots or IRC bots can be launched, etc) - it won't be a real
true 'system compromise' but it will cost you bandwidth, resources,
On 4/11/08, Cliff Wells <cliff at develix.com> wrote:
> On Fri, 2008-04-11 at 21:26 +0100, Ed W wrote:
> > > IMHO it's much easier to setup a VPS (e.g. OpenVZ) than to fiddle with
> > > most of the security frameworks (the most common question about SELinux
> > > is how to disable it). You get adequate isolation at minimal cost, and
> > > your app runs in a fairly standard environment.
> > >
> > Well actually you get no extra protection against your app being broken
> > into to, you just limit the damage caused.
> But that's pretty much the case no matter what you do. The security
> frameworks simply prevent a broken/hacked application from being used to
> further compromise the system. Using the example you gave earlier, to
> prevent a hacked PHP application from opening a network connection. They
> didn't prevent the PHP app from being hacked in the first place (nor
> could they).
> Things like AppArmour can help prevent particular exploits in binary
> applications (specifically buffer overruns leading to the execution of
> arbitrary code or reading of protected areas), but in general the
> purpose of security frameworks such as SELinux and GRSEC is to limit the
> damage post-exploit. This is pretty much the same for a VPS. The scope
> and method of containment is all that differs.
More information about the nginx