From: pebenito@ieee.org (Chris PeBenito) Date: Tue, 29 Nov 2016 19:23:35 -0500 Subject: [refpolicy] [PATCH] Apache OpenOffice module In-Reply-To: References: <1480113700.5692.4.camel@trentalancia.net> Message-ID: <848bd66a-ead2-97e3-b952-265ab5d8c903@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 11/29/16 06:51, Dominick Grift wrote: > On 11/29/2016 02:48 AM, Chris PeBenito wrote: >> On 11/26/16 08:53, Dominick Grift via refpolicy wrote: >>> On 11/25/2016 11:41 PM, Guido Trentalancia via refpolicy wrote: >>>> This is a minimal patch that I am testing to support Apache OpenOffice >>>> with its own module. >>>> >>>> The file contexts (and initial tests) are based on the default >>>> installation path for version 4 of the office suite. >>>> >>>> Signed-off-by: Guido Trentalancia >>>> --- >> [...] >>> >>> I am personally of the opinion that this module probably will not cut it >>> in the end. Basically because it's too limited, especially considering >>> that it uses dbus. >> >> I'm unclear what the purpose of this policy is. Users aren't going to >> expect this kind of limitation. They should be able to edit whatever >> their user domain has access to, i.e. the same reason vim doesn't have a >> policy. >> > > vim is a text editor. open/libre office is a office suite. > > I do not believe that anyone expects the latter to be able to manage > config, data and cache files. > > If you want to enforce some integrity on the desktop then you have to > draw the line somewhere sometimes. I suppose that is what enforcing > integrity is all about after all... In this case, what integrity is being enforced? Integrity of the user data? That's not covered here as it can manage the user data. Maybe not the configs, but user data is of much more consequence. It's not preventing network access, particularly to http, so there's nothing preventing it from sending out the user data either. -- Chris PeBenito