Date: Fri, 22 Jan 2010 17:14:47 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: DAve <dave.list@pixelhammer.com> Cc: 'User Questions' <freebsd-questions@freebsd.org> Subject: Re: Securing cgi scripts Message-ID: <4B59DD07.6020505@infracaninophile.co.uk> In-Reply-To: <4B59BC65.3040905@pixelhammer.com> References: <4B59BC65.3040905@pixelhammer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD92050B13EBD01CF22853909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
DAve wrote:
> Good morning all,
>=20
> I have been working on an issue here where I am being asked if we can
> support letting clients install and run their own CGI scripts on a
> shared vhost. I have tried sbox and cgiwrap, both which worked, but the=
y
> cannot stop the one test of reading the /etc/passwd file.
>=20
> Forgive my ignorance here, but I thought CGIs were gone long ago and
> have not messed with them in over ten years. If a client really needs a=
> specfic CGI script hosted, I check it out thoroughly and install it
> where they cannot reach it. Those instances are very very rare.
>=20
> It looks to me like the only way to keep a client contained is to run
> their CGIs chrooted. Would this be correct?
CGI programs run in the OS filesystem context, so there's generally nothi=
ng
to stop them reading /etc/passwd. They are essentially the same level of=
risk as an unprivileged user login account. =20
Mind you, pretty exactly the same thing applies if you let your customers=
supply their own PHP or perl or other programs which run using an interpr=
eter
embedded in the apache process: they can access anything accessible to th=
e
web server process. =20
I should point out that unprivileged users are *meant* to be able to
read /etc/passwd -- it's /etc/master.passwd that has the sensitive stuff
in it.
In fact, the bigger problem with running CGI programs from a shared
webserver is that they generally all run using the same security
credentials; those of the web server (www:www by default) -- which
potentially lets all your different customers tread on each others toes. =
suexec(8) is the stock solution to that problem.
If you really want to keep your customers properly separated, then send
them to jail(8). While giving them each a separate jail with a full=20
install of apache etc. certainly does work, it implies dedicating at leas=
t
an IP per customer. You could avoid that by still keeping a single apach=
e=20
instance but use something like an fCGI process per customer running each=
in=20
separate jails hanging off the loopback i/f.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enigD92050B13EBD01CF22853909
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAktZ3Q0ACgkQ8Mjk52CukIzsLgCeLK7hxMFppZDBH7KLGxrZJGYF
1ysAn1FO6VVXMjDeHhIohK/vyY9XiwFw
=5a2X
-----END PGP SIGNATURE-----
--------------enigD92050B13EBD01CF22853909--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B59DD07.6020505>