incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <rabas...@gmail.com>
Subject Re: [PROPOSAL] Keeping AOO Attack Surface Small
Date Fri, 25 Nov 2011 13:48:46 GMT
On Nov 25, 2011, at 1:42 AM, "Dennis E. Hamilton"
<dennis.hamilton@acm.org> wrote:

> Rob,
>
> Thanks for this.  You're right, I did not consider the enterprise case.
>

So maybe think of our goal as supporting a defined policy, where such
policy might have an out-of-the-box default, but can also be
redefined.

Ideally such policy definition can be done without requiring source
code changes. By deployers.  Im thinking of MS Office Resource Kit,
etc.

> I would say that this is the default for binaries that are built for download by whoever
from Apache OpenOffice download locations.
>
> I agree that ways to modify installs for internal use of organizations (but not distribution
as official Apache OpenOffice downloads) is a valuable addition.  This could be by rebuilding
or by configuration tools for making enterprise redistributions.  How that impacts the attack
surface of the product also needs to be considered and what the defense/detection can be becomes
important (to AOO and those enterprise customizers).
>
> Some enterprises may also want to restrict operations more than these proposals would
require.
>
> Some doing is senseless if the end-game is not shared and understood and the arrows are
good for that target.  Sometimes policies and practices are essential.
>
> -----Original Message-----
> From: Rob Weir [mailto:robweir@apache.org]
> Sent: Thursday, November 24, 2011 13:55
> To: ooo-dev@incubator.apache.org
> Subject: Re: [PROPOSAL] Keeping AOO Attack Surface Small
>
> On Thursday, November 24, 2011, Dennis E. Hamilton <orcmid@apache.org>
> wrote:
>> 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.
>>
>
> 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
> policies..
>
> 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 [mailto:rabastus@gmail.com]
>> 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
>>>
>>
>>
>

Mime
View raw message