Re: [gentoo-portage-dev] webapp-config and webapps

[Stuart Herbert]

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 apps 
out there with their own (normally web-based) configuration support.  That's 
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 
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.



> How would you implement an automatic open_basedir restriction in
> PHP, after a web application was installed?

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 
php.ini.

I'd do what I do on my boxes at work.  I'd create a per-app-instance config 
file which contained the necessary settings, and have apache include it the 
next time it was SIGHUP'd.

How would I decide whether an open_basedir restriction was required?  That is 
a policy decision, which would be managed through the vhost-tools.

> I certainly wouldn't want my
> 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 any 
tool from putting the configuration in place ready for a scheduled change.

Again, scheduling config reloads is a policy decision, which could be managed 
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 
not what I intend to do.  I'm intending to provide tools which will generate 
config files for the various apps - and which will get the information from 
config files maintained by the local administrator.

There aren't that many scripts that modify php.ini - and any script that does 
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 specific
> 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 the 
ease of installation of your packages.

> I can take the necessary steps to reasonably secure my web services and can
> provide information that would instruct others on how to do the same,
> however there is no way I could explain every possible combination of every
> 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,

If it's too complicated to do by hand, then it definitely needs automating

> it's not practical and it's not feasible;

When was the last time you installed a Windows application by hand?  Or a 
non-web-app on Linux?  Most apps in the world can be installed automatically; 
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 why
> 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 
dial-up account' type hosting, most of the hosting over here in the UK 
provides shell access.  

It's not possible to support non-privileged users running webapp-config with 
the default Apache 2 MPM, as these users can't perform the chown operations 
that the tool needs to do.  We could provide a setuid-safe script to do this, 
but that's not top of my todo list.

The problem with each web-based package providing its own package management 
is that you're left with widely varying quality.  You also have the problem 
that it's harder to lock down a site and prevent unauthorised change.  And 
these tools don't work too well on secured and/or disconnected intranets (and 
these are surprising common in the public sector at least).  Tools that 
extend Portage - tools that allow for disconnected upgrades - still have 
their advantages :)

What you describe is how things are today.  If the tools existed to do these 
things for you, would you still want to live in today?  Even if you do, there 
are plenty of people out there who do not.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@g.o
Gentoo Developer                                       http://www.gentoo.org/
                                                   http://stu.gnqs.org/diary/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--