Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?4B59DD07.6020505>