From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12038 invoked from network); 28 Oct 2004 23:31:15 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 28 Oct 2004 23:31:15 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CNJjf-0008JB-0A for arch-gentoo-portage-dev@lists.gentoo.org; Thu, 28 Oct 2004 23:31:15 +0000 Received: (qmail 9277 invoked by uid 89); 28 Oct 2004 23:31:13 +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 25944 invoked from network); 28 Oct 2004 23:31:13 +0000 From: Stuart Herbert Reply-To: stuart@gentoo.org Organization: Gentoo Linux Project To: gentoo-portage-dev@lists.gentoo.org Date: Fri, 29 Oct 2004 00:31:05 +0100 User-Agent: KMail/1.7.1 References: <1098993757.9091.107.camel@www.toruslaptop.com> <200410282313.11819.stuart@gentoo.org> <200410281552.17634.anthony@ectrolinux.com> In-Reply-To: <200410281552.17634.anthony@ectrolinux.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1566593.3d6H1gEtdv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200410290031.08751.stuart@gentoo.org> Subject: Re: [gentoo-portage-dev] webapp-config and webapps X-Archives-Salt: 77048c2f-60bc-4aa0-9d60-42691edae9bb X-Archives-Hash: edb1037baf92c653128d52771ffbc0b0 --nextPart1566593.3d6H1gEtdv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 28 October 2004 23:52, Anthony Gorecki wrote: > 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 > auto-configuring web-based apps." That's auto-configuration, not self-configuration. There are web-based app= s=20 out there with their own (normally web-based) configuration support. That'= s=20 what I'd call self-configuration. > And in the case of the above, the tip of a sword is as close to playing > nicely as those applications will come. > > *sighs at his application frameworks* That's true today. It'll stay true tomorrow if no-one does anything to try= =20 and change it. But if we try - who knows what we can achieve? > I personally would not trust webapp-config to reconfigure my web server or > modify web service configuration files, especially considering that I > replaced the stock configurations with my own as soon as I installed > Apache.=20 > How would you implement an automatic open_basedir restriction in=20 > PHP, after a web application was installed?=20 open_basedir can only be set in php.ini or the Apache config file. It's always best to avoid setting anything other than system-wide defaults = in=20 php.ini. I'd do what I do on my boxes at work. I'd create a per-app-instance config= =20 file which contained the necessary settings, and have apache include it the= =20 next time it was SIGHUP'd. How would I decide whether an open_basedir restriction was required? That = is=20 a policy decision, which would be managed through the vhost-tools. > I certainly wouldn't want my=20 > Apache processes receiving a SIGHUP after every software installation to > reload the configuration, which is the only place open_basedir may be > altered. The SIGHUP is required for a change to take effect. That doesn't prevent a= ny=20 tool from putting the configuration in place ready for a scheduled change. Again, scheduling config reloads is a policy decision, which could be manag= ed=20 through the vhost-tools. > Compounding the problem, many scripts heavily modify the PHP runtime > configuration directives: how would an automated tool be able to factor in > all the necessary information for every web application? This doesn't seem > realistic. You're assuming that the tool has to learn about each app, me thinks. That= 's=20 not what I intend to do. I'm intending to provide tools which will generat= e=20 config files for the various apps - and which will get the information from= =20 config files maintained by the local administrator. There aren't that many scripts that modify php.ini - and any script that do= es=20 is (as far as I'm concerned) broken. > IMHO, an automated tool would never be suitable for securing a web > environment, composed of a non-homogeneous solution of different > applications. I simply don't see how it's possible to secure against every > possible method of script exploitation (or even a marginal majority) for > every web language (or even one web language), without knowing the specif= ic > workings of the scripts in question. I hope to prove you wrong in time. > As an "upstream provider," I would also never waste my time providing the > specifications to any tool designed for such purposes. I'm sorry to hear that you think it's a waste of time to try and improve th= e=20 ease of installation of your packages. > I can take the necessary steps to reasonably secure my web services and c= an > provide information that would instruct others on how to do the same, > however there is no way I could explain every possible combination of eve= ry > possible scenario to every possible user on every possible configuration. Why are there so many scenarios where your services would be insecure? > It doesn't make sense,=20 If it's too complicated to do by hand, then it definitely needs automating > it's not practical and it's not feasible;=20 When was the last time you installed a Windows application by hand? Or a=20 non-web-app on Linux? Most apps in the world can be installed automaticall= y;=20 there's no reason why web-based apps should be treated as a special case. > Is it? A large number of hosting providers do not even allow their clients > to access a shell console, nevermind Portage derivatives. In the same way, > I would never allow one of my -client's- web applications to have any > influence whatsoever on the operations of -my- web server. Most websites > have no concept of a package manager, in the traditional sense: this is w= hy > my web applications provide their own means of filesystem management and > software updates. At present, the only viable package management system I > see for web applications is one they provide themselves. My experience is different from yours. Aside from the '50Mb free with your= =20 dial-up account' type hosting, most of the hosting over here in the UK=20 provides shell access. =20 It's not possible to support non-privileged users running webapp-config wit= h=20 the default Apache 2 MPM, as these users can't perform the chown operations= =20 that the tool needs to do. We could provide a setuid-safe script to do thi= s,=20 but that's not top of my todo list. The problem with each web-based package providing its own package managemen= t=20 is that you're left with widely varying quality. You also have the problem= =20 that it's harder to lock down a site and prevent unauthorised change. And= =20 these tools don't work too well on secured and/or disconnected intranets (a= nd=20 these are surprising common in the public sector at least). Tools that=20 extend Portage - tools that allow for disconnected upgrades - still have=20 their advantages :) What you describe is how things are today. If the tools existed to do thes= e=20 things for you, would you still want to live in today? Even if you do, the= re=20 are plenty of people out there who do not. Best regards, Stu =2D-=20 Stuart Herbert stuart@gentoo.o= rg Gentoo Developer http://www.gentoo.or= g/ http://stu.gnqs.org/diar= y/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint =3D 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C =2D- --nextPart1566593.3d6H1gEtdv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.9.10 (GNU/Linux) iD8DBQBBgYE8DC+AuvmvxXwRAr8yAJ9vtlu+P/2R30Kv9Stj9C45sTt2YwCdGUYe 3zQGGsJiCyV/74VL53ZGx8A= =NDtR -----END PGP SIGNATURE----- --nextPart1566593.3d6H1gEtdv--