| 1 |
On Thursday 28 October 2004 3:13 pm, Stuart Herbert wrote: |
| 2 |
> Hrm ... I haven't made any comment on self-configuring web applications. |
| 3 |
|
| 4 |
"We know that webapp-config needs improvements, especially in the area of |
| 5 |
auto-configuring web-based apps." |
| 6 |
|
| 7 |
|
| 8 |
> > In addition, some web applications will download their own source files |
| 9 |
> > on demand and update themselves on demand, in a manner similar to |
| 10 |
> > Portage. webapp-config would be completely unsuitable for these |
| 11 |
> > applications. |
| 12 |
> |
| 13 |
> And so is Portage ;-) |
| 14 |
> |
| 15 |
> Until UPSTREAM apps play nicely, this will always be a problem with any |
| 16 |
> tool that anyone writes. And UPSTREAM can't play nicely until there's a |
| 17 |
> tool to play nicely with. |
| 18 |
|
| 19 |
And in the case of the above, the tip of a sword is as close to playing nicely |
| 20 |
as those applications will come. |
| 21 |
|
| 22 |
*sighs at his application frameworks* |
| 23 |
|
| 24 |
|
| 25 |
> > In these cases, additional backend configuration is necessary |
| 26 |
> |
| 27 |
> The next version of webapp-config will be able to handle that sort of |
| 28 |
> configuration too. We need to provide a tool to do it; we can't expect all |
| 29 |
> of our users to have the skills to secure a PHP app by hand. |
| 30 |
|
| 31 |
I personally would not trust webapp-config to reconfigure my web server or |
| 32 |
modify web service configuration files, especially considering that I |
| 33 |
replaced the stock configurations with my own as soon as I installed Apache. |
| 34 |
How would you implement an automatic open_basedir restriction in PHP, after a |
| 35 |
web application was installed? I certainly wouldn't want my Apache processes |
| 36 |
receiving a SIGHUP after every software installation to reload the |
| 37 |
configuration, which is the only place open_basedir may be altered. |
| 38 |
|
| 39 |
Compounding the problem, many scripts heavily modify the PHP runtime |
| 40 |
configuration directives: how would an automated tool be able to factor in |
| 41 |
all the necessary information for every web application? This doesn't seem |
| 42 |
realistic. |
| 43 |
|
| 44 |
IMHO, an automated tool would never be suitable for securing a web |
| 45 |
environment, composed of a non-homogeneous solution of different |
| 46 |
applications. I simply don't see how it's possible to secure against every |
| 47 |
possible method of script exploitation (or even a marginal majority) for |
| 48 |
every web language (or even one web language), without knowing the specific |
| 49 |
workings of the scripts in question. |
| 50 |
|
| 51 |
As an "upstream provider," I would also never waste my time providing the |
| 52 |
specifications to any tool designed for such purposes. |
| 53 |
|
| 54 |
I can take the necessary steps to reasonably secure my web services and can |
| 55 |
provide information that would instruct others on how to do the same, however |
| 56 |
there is no way I could explain every possible combination of every possible |
| 57 |
scenario to every possible user on every possible configuration. It doesn't |
| 58 |
make sense, it's not practical and it's not feasible; the same applies for a |
| 59 |
unified "secure-it" tool, regardless of how idealistic the principle of its |
| 60 |
creation. |
| 61 |
|
| 62 |
|
| 63 |
> > webapp-config should be completely oblivious to this, as these safeguards |
| 64 |
> > would obviously beyond the scope of the program; however, it should |
| 65 |
> > support the functionality if it is required. |
| 66 |
> |
| 67 |
> Why 'obviously' beyond the scope? |
| 68 |
|
| 69 |
See the above. |
| 70 |
|
| 71 |
|
| 72 |
> Every web-based app installed on practically every platform out there is |
| 73 |
> hampered by the limited capabilities of package managers and current |
| 74 |
> automated installers. |
| 75 |
> |
| 76 |
> We're going to have to get there a step at a time, but I think it's worth |
| 77 |
> the effort. |
| 78 |
|
| 79 |
Is it? A large number of hosting providers do not even allow their clients to |
| 80 |
access a shell console, nevermind Portage derivatives. In the same way, I |
| 81 |
would never allow one of my -client's- web applications to have any influence |
| 82 |
whatsoever on the operations of -my- web server. Most websites have no |
| 83 |
concept of a package manager, in the traditional sense: this is why my web |
| 84 |
applications provide their own means of filesystem management and software |
| 85 |
updates. At present, the only viable package management system I see for web |
| 86 |
applications is one they provide themselves. |
| 87 |
|
| 88 |
|
| 89 |
> Take a look at /etc/vhosts/webapp-config and the man page for |
| 90 |
> webapp-config.5. The support you need is there. I don't run any of own |
| 91 |
> sites from /var/www. |
| 92 |
|
| 93 |
Thanks for the clarification. |
| 94 |
|
| 95 |
|
| 96 |
> 'localhost' *is* currently hard-coded as the hostname that an app is |
| 97 |
> installed into when USE=-vhosts. This is something we can change. |
| 98 |
|
| 99 |
Please feel free :) |
| 100 |
|
| 101 |
|
| 102 |
-- |
| 103 |
Anthony Gorecki |
| 104 |
Ectro-Linux Foundation |
Archives