From: dac.override@gmail.com (Dominick Grift)
Date: Sun, 14 Aug 2016 23:35:56 +0200
Subject: [refpolicy] [PATCH] Update for the gnome policy and file
	contexts
In-Reply-To: <713300416.997221.1471210427783.JavaMail.open-xchange@popper06.register.it>
References: <1471099545.21480.27.camel@trentalancia.net>
	<e4796821-1139-a8d5-e29e-91ad07c603ac@gmail.com>
	<760247119.997218.1471209257066.JavaMail.open-xchange@popper06.register.it>
	<e452a531-e5ea-202e-134d-936a390f9a88@gmail.com>
	<713300416.997221.1471210427783.JavaMail.open-xchange@popper06.register.it>
Message-ID: <c33ec938-d941-f023-5da1-64fd613a3b43@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/14/2016 11:33 PM, Guido Trentalancia wrote:
> Hello Dominick.
> 
>> On 08/14/2016 11:14 PM, Guido Trentalancia wrote:
>>> Hello Dominick !
>>>
>>> Finally I am able to clarify one of the two open questions about the gnome
>>> module...
>>>
>>>> On the 13th of August 2016 at 16.51 Dominick Grift <dac.override@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>> On 08/13/2016 04:45 PM, Guido Trentalancia wrote:
>>>>> Update for the gnome module:
>>>>>
>>>>> - a new gstreamer_orcexec_t type and file context is introduced
>>>>>   to support the OIL Runtime Compiler (ORC) optimized code
>>>>>   execution (used for example by pulseaudio);
>>>>> - add support for more permissions needed in gconfd_t and gnome
>>>>>   keyring domains;
>>>>> - add support for a few needed fs and kernel permissions. 
>>>>>
>>>>> This patch should be applied before applying the pulseaudio patch.
>>>>>
>>>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>>>> ---
>>>>>  policy/modules/contrib/gnome.fc |    7 ++
>>>>>  policy/modules/contrib/gnome.if |   99
>>>>> +++++++++++++++++++++++++++++++++++++++-
>>>>>  policy/modules/contrib/gnome.te |    8 +++
>>>>>  3 files changed, 112 insertions(+), 2 deletions(-)
>>>
>>> [...]
>>>
>>>>> --- refpolicy-git-06082016-orig/policy/modules/contrib/gnome.if	2016-08-13
>>>>> 16:02:14.950814302 +0200
>>>>> +++ refpolicy-git-06082016/policy/modules/contrib/gnome.if	2016-08-13
>>>>> 00:55:24.980149003 +0200
>>>>> @@ -1,4 +1,4 @@
>>>>> -## <summary>GNU network object model environment.</summary>
>>>>> +
>>>>>  
>>>>>  ########################################
>>>>>  ## <summary>
>>>>> @@ -100,9 +100,15 @@ template(`gnome_role_template',`
>>>>>  
>>>>>  	allow $3 gnome_keyring_tmp_t:sock_file { relabel_sock_file_perms
>>>>> manage_sock_file_perms };
>>>>>  
>>>>> +	userdom_manage_user_home_content_dirs($1_gkeyringd_t)
>>>>> +	userdom_manage_user_home_content_files($1_gkeyringd_t)
>>>>> +	userdom_manage_user_home_content_sockets($1_gkeyringd_t)
>>>>> +
>>>>
>>>> I don't like this, and I dont understand it
>>>
>>> It's needed to write .xsession-errors and the .cache subdirectory in the
>>> user
>>> home.
>>>
>>> It is quite important, as the latter is used, amongst other things, to store
>>> user credentials: for example, when the user enters the password in the
>>> evolution mail client to retrieve his/her mail, then the password entered is
>>> stored in the cache and the user does not need to enter the password again
>>> when
>>> the mail is received again periodically later.
>>>
>>
>> And the .xsessions_errors file is not mislabeled? (e.g. is that supposed
>> to be user_home_t?)
>>
>> As for ~/.cache issue. Probably best to hold on to that for now as
>> chances are that refpolicy will soon associate a different type with
>> that directory. Thus that scenario might change again soon.
>>
>> You did not clarify the
>> userdom_manage_user_home_content_sockets($1_gkeyringd_t)
>>
>> But i am pretty sure that this socket should not be user_home_t.
> 
> Might be sensitive sockets, they are named "control", "pkcs11", "ssh", "gpg" and
> are located in .cache/keyring-*/
> 
> They are currently labeled user_home_t.
> 
> What do you suggest to do ?
> 

I would hold off on this until the XDG spec types are implemented
(~/.cache) then create a private gkeyring_cache_home_t type for
~/.cache/keyring

>>> I hope this clarifies the matter.
>>>
>>> I am checking the other issue (socket creation in /tmp) by testing the
>>> policy
>>> you suggested but unfortunately, I can anticipate that there are issues.
>>> Will
>>> let you know more precisely when I have finished testing it.
> 
> Best regards,
> 
> Guido
> 


-- 
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/20160814/b2191f47/attachment-0001.bin