From: pebenito@ieee.org (Chris PeBenito) Date: Thu, 1 Dec 2016 19:42:13 -0500 Subject: [refpolicy] [PATCH] Apache OpenOffice module In-Reply-To: <5ebcef67-c5cd-2c1d-0ed3-3b2178c1c88b@gmail.com> References: <1480113700.5692.4.camel@trentalancia.net> <848bd66a-ead2-97e3-b952-265ab5d8c903@ieee.org> <5ebcef67-c5cd-2c1d-0ed3-3b2178c1c88b@gmail.com> Message-ID: <384904fc-7486-e10f-001a-6ff58520967b@ieee.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 11/30/16 01:52, Dominick Grift wrote: > On 11/30/2016 01:23 AM, Chris PeBenito wrote: >> 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. > > I would argue that in a desktop system the most sensitive data is > config, cache and data. So integrity should be enforced on this content. > (e.g.) strictly restrict access to the private types of config, data and > cache. > > .gnupg is config, often it houses private key files. Only gnupg should > be able to access this file directly. this key is like your identity. It > has to be protected. .ssh is ssh-client config it might have private key > files. These are like your authentication credentials and should be > protected and only ssh client should have access to it. The > gnome-keyring data has sensitive info and should be protected. Many This alone is what convinces me to merge it. I still think that generic user data is still the highest priority by many magnitudes. If I had a copy of my tax forms or health info (or pick some other extremely personal, sensitive document) on my system, I would be FAR angrier if that was compromised, compared to my GPG key. GPG keys can be revoked and passwords can be changed. -- Chris PeBenito