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:[email protected]] Sent: Friday, November 18, 2011 06:42 To: [email protected] 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 > <[email protected]> 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
