On Nov 25, 2011, at 1:42 AM, "Dennis E. Hamilton" <[email protected]> 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:[email protected]] > Sent: Thursday, November 24, 2011 13:55 > To: [email protected] > Subject: Re: [PROPOSAL] Keeping AOO Attack Surface Small > > On Thursday, November 24, 2011, Dennis E. Hamilton <[email protected]> > 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:[email protected]] >> Sent: Thursday, November 24, 2011 09:40 >> To: [email protected] >> Subject: Re: GPL'd dictionaries (was Re: ftp.services.openoffice.org?) >> >> On Nov 24, 2011, at 12:17 PM, "Dennis E. Hamilton" <[email protected]> > 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:[email protected]] >>> Sent: Thursday, November 24, 2011 05:29 >>> To: [email protected] >>> 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 >>> >> >> >
