You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2011/11/18 13:53:02 UTC
Install configuration management
Moving this to its own thread....
On Fri, Nov 18, 2011 at 3:31 AM, Gianluca Turconi
<pu...@letturefantastiche.com> wrote:
> In data 17 novembre 2011 alle ore 22:26:18, Rob Weir <ro...@apache.org> ha
> scritto:
>
>> I'm OK with that. This is what I was thinking of as #3 below. So
>> saying, "You do not have a dictionary installed, would you like to see
>> a list of 3rd party dictionaries?" is fine. You then can launch a
>> browser or have an in-app extension browser. But we're not choosing
>> among the alternatives. We're inviting the user to do this. Of
>> course, a 3rd party could take AOO, modify it and constrain the
>> choices further, bundle dictionaries, etc.
>
> Are you talking about an after-installation wizard or something similar,
> aren't you?
>
> This means that AOOo wouldn't be a ready-to-use product just after the
> installation. That's fine for individual installations.
>
> However, what about network installations?
>
> I think many IT admins *really* don't like users' installation of add-ons...
> ;-)
>
> Wouldn't it be better to have such procedure directly included into the
> installation of the application?
>
> There would be 2 options:
>
> a) a normal installation (plain vanilla AOOo);
>
> b) a custom Installation (vanilla AOOo + selected and downloadable
> dictionaries, templates, everything else).
>
I think this is a good idea. A large organization will want to do a
network install with a customized configuration:
1) Pre-install extensions, both open source ones but also custom,
in-house extensions
2) Install custom document templates per corporate standards
3) Modify configuration settings, such as for default file format, etc.
It is good to look at what Microsoft has done here with there Office
Customization Tool:
http://technet.microsoft.com/en-us/library/cc179097.aspx
And one thing to consider: for a very large company, an international
company like IBM, the network install would need to have many language
packs and dictionaries available, since we have employees all over the
world. So the deployment options become more complex.
-Rob
> Just my 2 cents.
>
> Regards,
>
> Gianluca
> --
> Lettura gratuita o acquisto di libri e racconti di fantascienza, fantasy,
> horror, noir, narrativa fantastica e tradizionale:
> http://www.letturefantastiche.com/
>
RE: Install configuration management
Posted by drew <dr...@baseanswers.com>.
On Fri, 2011-11-18 at 12:07 -0800, Dennis E. Hamilton wrote:
> When the download and execution is *performed* by Apache OpenOffice, the vulnerability is now ours. That needs to be obvious too.
Howdy,
Just a quick aside here - the idea of organizations using local
extension and template repositories isn't completely out of the blue -
as I recall there where a couple of school systems in the US that did
just this and I a corporation in Japan...I'll try to find my old notes
on that and pass along what I have, if I still have it.
Thanks
Drew Jensen
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Friday, November 18, 2011 11:58
> To: ooo-dev@incubator.apache.org
> Subject: Re: Install configuration management
>
> On Fri, Nov 18, 2011 at 2:11 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
> > I think this is all very interesting.
> >
> > I want to point out that any situation where code is downloaded for execution under the user's privileges while running Apache OpenOffice is an avenue for attack by injection of malicious code and also data mining the user account.
> >
>
> I want to point out that any situation where code is downloaded for
> execution under the user's privileges while *not running* Apache
> OpenOffice is *also* an avenue for attack by injection of malicious
> code and also data mining the user account.
>
> This is just stating the obvious in too many words.
>
> -Rob
>
>
RE: Install configuration management
Posted by "Dennis E. Hamilton" <de...@acm.org>.
When the download and execution is *performed* by Apache OpenOffice, the vulnerability is now ours. That needs to be obvious too.
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Friday, November 18, 2011 11:58
To: ooo-dev@incubator.apache.org
Subject: Re: Install configuration management
On Fri, Nov 18, 2011 at 2:11 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I think this is all very interesting.
>
> I want to point out that any situation where code is downloaded for execution under the user's privileges while running Apache OpenOffice is an avenue for attack by injection of malicious code and also data mining the user account.
>
I want to point out that any situation where code is downloaded for
execution under the user's privileges while *not running* Apache
OpenOffice is *also* an avenue for attack by injection of malicious
code and also data mining the user account.
This is just stating the obvious in too many words.
-Rob
Re: Install configuration management
Posted by Rob Weir <ro...@apache.org>.
On Fri, Nov 18, 2011 at 2:11 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> I think this is all very interesting.
>
> I want to point out that any situation where code is downloaded for execution under the user's privileges while running Apache OpenOffice is an avenue for attack by injection of malicious code and also data mining the user account.
>
I want to point out that any situation where code is downloaded for
execution under the user's privileges while *not running* Apache
OpenOffice is *also* an avenue for attack by injection of malicious
code and also data mining the user account.
This is just stating the obvious in too many words.
-Rob
RE: Install configuration management
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I think this is all very interesting.
I want to point out that any situation where code is downloaded for execution under the user's privileges while running Apache OpenOffice is an avenue for attack by injection of malicious code and also data mining the user account.
The authentication of downloaded extensions (and templates containing whatever they contain that might be executed) becomes an important matter. Generally following URLs silently in an extension or template is also a point of vulnerability if it can lead to a script being run as if it is local code.
It is likely overdue that these provisions of OpenOffice.org be subject to careful security review and threat modeling to safeguard user's not realizing what they might be consenting to, and how to minimize the related risks.
-----Original Message-----
From: Jürgen Schmidt [mailto:jogischmidt@googlemail.com]
Sent: Friday, November 18, 2011 06:42
To: ooo-dev@incubator.apache.org
Subject: Re: Install configuration management
On 11/18/11 2:40 PM, Gianluca Turconi wrote:
> In data 18 novembre 2011 alle ore 13:53:02, Rob Weir
> <ro...@apache.org> ha scritto:
>
>> 1) Pre-install extensions, both open source ones but also custom,
>> in-house extensions
we can probably simplify the mechanism here. As far as in know LibO
discussed an approach to scan a specific directory for new extensions.
The same would be possible for templates.
>> 2) Install custom document templates per corporate standards
i think i have mentioned earlier that here is a lot of potential to
improve the user experience as well as the overall deployment options.
A customizable template and extension repository that can be changed to
a company internal repo to ensure that only approved extensions and
templates are used.
Both repos should be much better integrated. For example the extension
repos cn be browsed directly from the extension dialog and extensions
are installed directly form here. The same for templates, a new template
dialog would allow to browse the specified template repo, mark templates
as favorite, allow download of templates for offline usage etc.
But again both repos are configurable. Ideally this can be switched off
by an administrator to prevent misuse in a company deployment. For
private usage we should have a public extension and template repo.
>> 3) Modify configuration settings, such as for default file format, etc.
>> It is good to look at what Microsoft has done here with there Office
>
all configuration settings can be changed via an extensions that for
example is deployed as shared extension in a network installation.
We had a very cool feature i the past that have allowed to load user
specific configuration settings from an ldap directory. And we had a
configuration management console that have allowed to tweak these
settings per user, per team or user group etc. Very useful for bigger
deployments. But i don't know if this is still supported i the
configuration. Anyway the configuration console is not available and we
would have to reimplement it.
> It would be a good thing to have some comments from people who have
> already managed large OOo network installations and from devs that have
> deep knowledge of the OOo installation phase in order to see how much
> work and difficulties there are either for a network OOo installation or
> for a hypothetical change of the current OOo installation options.
as always a lot of work that have to done by somebody ;-)
Juergen
Re: Install configuration management
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 11/18/11 2:40 PM, Gianluca Turconi wrote:
> In data 18 novembre 2011 alle ore 13:53:02, Rob Weir
> <ro...@apache.org> ha scritto:
>
>> 1) Pre-install extensions, both open source ones but also custom,
>> in-house extensions
we can probably simplify the mechanism here. As far as in know LibO
discussed an approach to scan a specific directory for new extensions.
The same would be possible for templates.
>> 2) Install custom document templates per corporate standards
i think i have mentioned earlier that here is a lot of potential to
improve the user experience as well as the overall deployment options.
A customizable template and extension repository that can be changed to
a company internal repo to ensure that only approved extensions and
templates are used.
Both repos should be much better integrated. For example the extension
repos cn be browsed directly from the extension dialog and extensions
are installed directly form here. The same for templates, a new template
dialog would allow to browse the specified template repo, mark templates
as favorite, allow download of templates for offline usage etc.
But again both repos are configurable. Ideally this can be switched off
by an administrator to prevent misuse in a company deployment. For
private usage we should have a public extension and template repo.
>> 3) Modify configuration settings, such as for default file format, etc.
>> It is good to look at what Microsoft has done here with there Office
>
all configuration settings can be changed via an extensions that for
example is deployed as shared extension in a network installation.
We had a very cool feature i the past that have allowed to load user
specific configuration settings from an ldap directory. And we had a
configuration management console that have allowed to tweak these
settings per user, per team or user group etc. Very useful for bigger
deployments. But i don't know if this is still supported i the
configuration. Anyway the configuration console is not available and we
would have to reimplement it.
> It would be a good thing to have some comments from people who have
> already managed large OOo network installations and from devs that have
> deep knowledge of the OOo installation phase in order to see how much
> work and difficulties there are either for a network OOo installation or
> for a hypothetical change of the current OOo installation options.
as always a lot of work that have to done by somebody ;-)
Juergen
Re: Install configuration management
Posted by Gianluca Turconi <pu...@letturefantastiche.com>.
In data 18 novembre 2011 alle ore 13:53:02, Rob Weir <ro...@apache.org>
ha scritto:
> 1) Pre-install extensions, both open source ones but also custom,
> in-house extensions
> 2) Install custom document templates per corporate standards
> 3) Modify configuration settings, such as for default file format, etc.
> It is good to look at what Microsoft has done here with there Office
It would be a good thing to have some comments from people who have
already managed large OOo network installations and from devs that have
deep knowledge of the OOo installation phase in order to see how much work
and difficulties there are either for a network OOo installation or for a
hypothetical change of the current OOo installation options.
Regards,
Gianluca
--
Lettura gratuita o acquisto di libri e racconti di fantascienza, fantasy,
horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/