From: dac.override@gmail.com (Dominick Grift) Date: Wed, 30 Nov 2016 07:52:23 +0100 Subject: [refpolicy] [PATCH] Apache OpenOffice module In-Reply-To: <848bd66a-ead2-97e3-b952-265ab5d8c903@ieee.org> References: <1480113700.5692.4.camel@trentalancia.net> <848bd66a-ead2-97e3-b952-265ab5d8c903@ieee.org> Message-ID: <5ebcef67-c5cd-2c1d-0ed3-3b2178c1c88b@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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 configuration files have sensitive info. For example you might have your nickserv password in .irssi/config. This should only be accessible by irssi else it can be used to impersonate you. there are a myriad of other sensitive files, but generally they all fall under config. cache or data. Types on contents that a office suite shouldnt have to have broad access to. (generic) User data and network access have low priority. (generic) User data is generally shared across domains. That is just its nature. So there is little we can do with SELinux to enforce integrity there (there is an option to implement a solution similar to the public_content_t solution we implemented in the system space but it would probably only be used my power users anyway). Network access well lets just say that we have better (or at least additional) tools to control access to the network. To me its all about protecting config , data and cache, and to govern who can run what, who can communicate with who etc. > -- 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/20161130/555f7b50/attachment.bin