From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10307 invoked from network); 28 Oct 2004 22:53:50 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 28 Oct 2004 22:53:50 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CNJ9S-0002eF-2D for arch-gentoo-portage-dev@lists.gentoo.org; Thu, 28 Oct 2004 22:53:50 +0000 Received: (qmail 3470 invoked by uid 89); 28 Oct 2004 22:53:48 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 5289 invoked from network); 28 Oct 2004 22:53:48 +0000 From: Anthony Gorecki To: gentoo-portage-dev@lists.gentoo.org Date: Thu, 28 Oct 2004 15:52:13 -0700 User-Agent: KMail/1.7.1 References: <1098993757.9091.107.camel@www.toruslaptop.com> <200410281448.23560.anthony@ectrolinux.com> <200410282313.11819.stuart@gentoo.org> In-Reply-To: <200410282313.11819.stuart@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1244905.n0vxMH1R3N"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410281552.17634.anthony@ectrolinux.com> X-Spam-Checker-Version: SpamAssassin 3.0.0-g3.0.0r1 (2004-09-13) on selene.nvanc.ectrolinux.com X-Spam-Status: No; -5.9 hits out of a required 6.0 X-Spam-Report: * -3.3 ALL_TRUSTED Did not pass through any untrusted hosts * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] Subject: Re: [gentoo-portage-dev] webapp-config and webapps X-Archives-Salt: 6d49ee85-b70a-479f-a89e-882ba5ce8f7a X-Archives-Hash: b9cff19b9821b0029b85ede82536eb33 --nextPart1244905.n0vxMH1R3N Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 28 October 2004 3:13 pm, Stuart Herbert wrote: > Hrm ... I haven't made any comment on self-configuring web applications. "We know that webapp-config needs improvements, especially in the area of=20 auto-configuring web-based apps." > > In addition, some web applications will download their own source files > > on demand and update themselves on demand, in a manner similar to > > Portage. webapp-config would be completely unsuitable for these > > applications. > > And so is Portage ;-) > > Until UPSTREAM apps play nicely, this will always be a problem with any > tool that anyone writes. And UPSTREAM can't play nicely until there's a > tool to play nicely with. And in the case of the above, the tip of a sword is as close to playing nic= ely=20 as those applications will come. *sighs at his application frameworks* > > In these cases, additional backend configuration is necessary > > The next version of webapp-config will be able to handle that sort of > configuration too. We need to provide a tool to do it; we can't expect a= ll > of our users to have the skills to secure a PHP app by hand. I personally would not trust webapp-config to reconfigure my web server or= =20 modify web service configuration files, especially considering that I=20 replaced the stock configurations with my own as soon as I installed Apache= =2E=20 How would you implement an automatic open_basedir restriction in PHP, after= a=20 web application was installed? I certainly wouldn't want my Apache processe= s=20 receiving a SIGHUP after every software installation to reload the=20 configuration, which is the only place open_basedir may be altered. Compounding the problem, many scripts heavily modify the PHP runtime=20 configuration directives: how would an automated tool be able to factor in= =20 all the necessary information for every web application? This doesn't seem= =20 realistic. IMHO, an automated tool would never be suitable for securing a web=20 environment, composed of a non-homogeneous solution of different=20 applications. I simply don't see how it's possible to secure against every= =20 possible method of script exploitation (or even a marginal majority) for=20 every web language (or even one web language), without knowing the specific= =20 workings of the scripts in question. As an "upstream provider," I would also never waste my time providing the=20 specifications to any tool designed for such purposes. I can take the necessary steps to reasonably secure my web services and can= =20 provide information that would instruct others on how to do the same, howev= er=20 there is no way I could explain every possible combination of every possibl= e=20 scenario to every possible user on every possible configuration. It doesn't= =20 make sense, it's not practical and it's not feasible; the same applies for = a=20 unified "secure-it" tool, regardless of how idealistic the principle of its= =20 creation. > > webapp-config should be completely oblivious to this, as these safeguar= ds > > would obviously beyond the scope of the program; however, it should > > support the functionality if it is required. > > Why 'obviously' beyond the scope? See the above. > Every web-based app installed on practically every platform out there is > hampered by the limited capabilities of package managers and current > automated installers. > > We're going to have to get there a step at a time, but I think it's worth > the effort. Is it? A large number of hosting providers do not even allow their clients = to=20 access a shell console, nevermind Portage derivatives. In the same way, I=20 would never allow one of my -client's- web applications to have any influen= ce=20 whatsoever on the operations of -my- web server. Most websites have no=20 concept of a package manager, in the traditional sense: this is why my web= =20 applications provide their own means of filesystem management and software= =20 updates. At present, the only viable package management system I see for we= b=20 applications is one they provide themselves. > Take a look at /etc/vhosts/webapp-config and the man page for > webapp-config.5. The support you need is there. I don't run any of own > sites from /var/www. Thanks for the clarification. > 'localhost' *is* currently hard-coded as the hostname that an app is > installed into when USE=3D-vhosts. This is something we can change. Please feel free :) =2D-=20 Anthony Gorecki Ectro-Linux Foundation --nextPart1244905.n0vxMH1R3N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.10 (GNU/Linux) iQIVAwUAQYF4Ib8NHCarD3E0AQLTqBAAnl00kRuC3/hPE7g0AdazMGZN4Iuo4YdE yeL7PBI/eoozceA+fJfBcy0KuAIifiVJrHvayjbczJ/Ew3Ct5M2uY5P/b30xlMnU Zie0cgGfbK/Pb/ZpEdP2oAv8N8Npn+2r3EYHPyPp9ROWlSNOyEIpV0KNbh9oSdZo zqnvhrp8LU+19DIGk0cLmkMHbB6GW6JaUKpD0Ty9KyIGqL9gCvceOYskiI+QDDef Dsa1EHobrDte4ofHZBOu6XHkpM/VFRaYlyWbcfdZvTpkvF4HyeSC+meTQK5dmWke B4qm0vdizkDUm0Nr3GBdM0bia7JiwZtlbkJCPM855YEH5CdxbghIEm6NwdQPhrfk gf/bPrBnwM7M6DdywlTUsV8Sp0w+L3r3ECAoijLhHHmeqkqPkJGOqw3TMPAgegGa fRqyfll79UDOdc1j/9zBDFxie7Rmqm+JQ5tpbdCpha2FsDVWaH3HcZU3JbYzR5vF nGQxNQhi71DOFwWzuOLle4Gbq0kNJ3UIcawwu2I9+WwHyNAfvTKP11jSNa5J9fIF 5nN2vaySzIa10T7a6kc1qeBMnm664EghZXHZTipoZ/ERlKETA+x1hahYtHSfaIdA fqDlqfo69NtZvMiVgIxtj4itxac8AOOii7QtzeCjOeu3nr4NpG2yu4/YoDN69K9L 5sCLf7TA0Yk= =JahP -----END PGP SIGNATURE----- --nextPart1244905.n0vxMH1R3N--