incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: [PROPOSAL] Keeping AOO Attack Surface Small
Date Thu, 24 Nov 2011 21:54:50 GMT
On Thursday, November 24, 2011, Dennis E. Hamilton <>
> Here are some proposal elements around the Attack Surface of Apache
OpenOffice and keeping it small:
>  P1. Extensions, supplements, and updates downloaded by the run-time
installer or product shall only be retrieved from URLs under Apache control
from sites operated by Apache infrastructure.  As a secondary defense,
authentication procedures will be used to confirm the provenance of such

I think you're trying to control what isn't yours.

For example it is perfectly reasonable for someone to install OpenOffice on
an enterprise environment and administrivrly configure for extensions to
come from an internal corporate server. In fact they may wish to disable
all but such extensions.

>  P2. Registration, checking for notices/updates, and any other access to
the web by the run-time should be opt-in and accomplished with the default
browser on the platform rather than within the running code.  Example 1:
Check for Updates in the Help menu is a link and selecting it has the
access performed by the default browser.  Example 2: User opt-ins to use of
on-line help.  Help requests to the internet are by providing
Apache-controlled URLs to the default browser.  The URLs are only to
Apache-hosted sites.

Again, we should not assume that we only have direct end users who only
receive the bode directly from us. We need to support s dude range of

General point: more groups than this PPMC set security policies for users.
We need to support admins, CIO office types as well as end users.

>  P3. Feature proposals shall be accompanied by assessment of whether or
not the attack surface of the product is expanded or not.  In most cases,
it will be easy to indicate that there is no concern.  Operations that can
give rise to silent access to networks or execution of code of unknown
origin are automatically suspect.  Operations that can do so while the
installer or product is operated under elevated privilege are automatically
considered serious.

Last I heard we were doing CTR.

>  P4. Existing features that cannot be assured to be outside the attack
surface of the product will, when recognized/reported as such, be targeted
for possible mitigation and other measures that shrink or eliminate the
attack surface contribution.
> These are pro-active measures not related to discovery of defect-related
vulnerabilities and existing exploits.
> I don't have a time-limit, or any default consensus, on this proposal.
Since you are not proposing to actually do anything yourself, there is
nothing here to seek lazy consensus on. We should avoid having the project
get tied down to a policy-crat morass and instead encourage a do- ocracy.

> -----Original Message-----
> From: Rob Weir []
> Sent: Thursday, November 24, 2011 09:40
> To:
> Subject: Re: GPL'd dictionaries (was Re:
> On Nov 24, 2011, at 12:17 PM, "Dennis E. Hamilton" <>
>> Three concerns, in addition to the ones Gianluca expressed already:
>> 1. The site is not working reliably
and is not operated by ASF.  Any in-product access to the site has to work
well and deal with unavailability.
> Do you have a proposal?
>> 2. I repeat my security concern over the increase of the product attack
surface when such downloading and installation is done internal to
operation of the product or its installer (which may already require
elevated privileges) without coming up with stronger means for
authenticating extension downloads.  (The dictionary case is for data, so
that is not quite so scary.  Authentication still matters.)
> Do you have a proposal?
>> 3. Any automatic update mechanism is a further concern.
> Do you have a proposal?
>> A security review activity is apparently missing from the development
and feature-decision process.  That is not going to serve us well
considering that this is a consumer product directed toward non-expert and
household users.  It must be assumed that our turn will come.
> Do you have a proposal?
>> -----Original Message-----
>> From: Andre Fischer []
>> Sent: Thursday, November 24, 2011 05:29
>> To:
>> Subject: Re: GPL'd dictionaries (was Re:
>> Hi all,
>> The last open item on the IP clearance wiki page is the removal of the
>> dictionary module from the AOO source code.  In order to provide a
>> developer build in the near future that does not contain category-x
>> licensed code we need a short term solution.
>> The central question is if we have to really remove the dictionaries at
>> all.  I did not see a definitive answer, so to be on the safe side I
>> assume that the dictionary module should be removed.
>> This leaves the question of a replacement.  One relatively straight
>> forward way seems to be to use the extensions that can be found at
>> Two ways of
>> using these extensions come to (my) mind:
>> A. Download the extension (assuming that the right locale can be
>> detected) automatically from the extension repository during
>> B. As last step of the installation, pop up a web page that, among other
>> things, tells the user that there is a dictionary extension that can be
>> installed and what its license is.
>> Variant A has the better usability but may not be acceptable from a
>> legal view.
>> Variant B would allow to display additional information and could offer
>> other (dictionary) extensions as well but would require more work to be
>> implemented.
>> One problem with both variants is that
>> already seems to have load problems.
>>  When everybody who installs Apache OpenOffice has to access this
>> server then its load would increase dramatically with a new release.
>> Unless there are objections I will remove the dictionary module now, to
>> clear the way for a category-x free developer build (or whatever its
>> name should be).
>> For the 3.4 release we have to decide on and implement a replacement.
>> Best regards,
>> Andre

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message