From: dac.override@gmail.com (Dominick Grift) Date: Fri, 2 Dec 2016 08:31:51 +0100 Subject: [refpolicy] [PATCH] Apache OpenOffice module In-Reply-To: <384904fc-7486-e10f-001a-6ff58520967b@ieee.org> References: <1480113700.5692.4.camel@trentalancia.net> <848bd66a-ead2-97e3-b952-265ab5d8c903@ieee.org> <5ebcef67-c5cd-2c1d-0ed3-3b2178c1c88b@gmail.com> <384904fc-7486-e10f-001a-6ff58520967b@ieee.org> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/02/2016 01:42 AM, Chris PeBenito wrote: > 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. > A copy of those faxes is probably stored on some insecure site(s)/database(s) on the web, something you have little control over. I agree though that generic user content is often also sensitive, but many agents just want access to it, restricting that by default would seriously harm experience and probably lead to situations where trying to restrict it defaats the purpose. Instead consider encryption for this purpose You can say that you can revoke keys and change passwords, but do consider that by then the harm may already have been done. And restoring "reputation" might not be as easy as it may seem. Also remember that the internet does not forget so easily. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161202/12b7c3d5/attachment-0001.bin