Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Reply-To: <orcmid@apache.org>
From: "Dennis E. Hamilton" <orcmid@apache.org>
To: <ooo-dev@incubator.apache.org>
Subject: [PROPOSAL] Keeping AOO Attack Surface Small
Date: Thu, 24 Nov 2011 13:28:30 -0800
Message-ID: <005901ccaaf0$038e6b80$0aab4280$@apache.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: Acyq8ABl2SnOvfnYRxaHQSokd0p19A==
Content-Language: en-us

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 downloads. =20

 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.

 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.

 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.

-----Original Message-----
From: Rob Weir [mailto:rabastus@gmail.com]=20
Sent: Thursday, November 24, 2011 09:40
To: ooo-dev@incubator.apache.org
Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)

On Nov 24, 2011, at 12:17 PM, "Dennis E. Hamilton" <orcmid@apache.org> =
wrote:

> Three concerns, in addition to the ones Gianluca expressed already:
>
> 1. The extensions.services.openoffice.org 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 [mailto:af@a-w-f.de]
> Sent: Thursday, November 24, 2011 05:29
> To: ooo-dev@incubator.apache.org
> Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?)
>
> 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
> http://extensions.services.openoffice.org/en/dictionaries. 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 =
installation.
>
> 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
> extensions.services.openoffice.org 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
>