[refpolicy] [PATCH] init: update the initrc_t domain policy

[dac.override@gmail.com (Dominick Grift)]

On 12/30/2016 09:19 PM, Guido Trentalancia via refpolicy wrote:
> On Fri, 30/12/2016 at 21.12 +0100, Dominick Grift via refpolicy wrote:
>> On 12/30/2016 09:09 PM, Guido Trentalancia via refpolicy wrote:
>>>
>>> On Fri, 30/12/2016 at 21.01 +0100, Dominick Grift via refpolicy
>>> wrote:
>>>>
>>>> On 12/30/2016 08:30 PM, Chris PeBenito via refpolicy wrote:
>>>>>
>>>>>
>>>>> On 12/29/16 17:49, Guido Trentalancia via refpolicy wrote:
>>>>>>
>>>>>>
>>>>>> Update the initrc_t domain policy in the init module with
>>>>>> some
>>>>>> missing permissions.
>>>>>>
>>>>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>>>>> ---
>>>>>>  policy/modules/kernel/terminal.if |   21
>>>>>> +++++++++++++++++++++
>>>>>>  policy/modules/system/init.te     |   19 +++++++++++++++++--
>>>>>>  2 files changed, 38 insertions(+), 2 deletions(-)
> 
> [...]
> 
>>>>>> +# plymouth
>>>>>> +kernel_stream_connect(initrc_t)
>>>>>
>>>>> Plymouth has a domain, so this seems unnecessary.
>>>>
>>>> Plymouthd is running from initramfs before policy is loaded. So
>>>> once
>>>> the
>>>> policy gets loaded and root is switched the kernel isid kicks in
>>>> and
>>>> associates kernel_t with the process
>>>
>>> Yes, I confirm. Plymouthd is running in the kernel_t domain because
>>> it
>>> is started before the policy is loaded.
>>>
>>
>> The question is then what is running in initrc_t in that event? is it
>> the plymouth client stream connecting to plymouthd?
>>
>> is the plymouth client an init_system_domain()?
> 
> The comment is misleading in some sense. It's plymouthd, I wrote
> "plymouth" referring to the package.
> 
> I'll fix the comment in the next version.

Yes ok, but then why does a process associated with initrc_t need to
stream connect to it?

what is that process running in initrc_t?

> 
> Regards,
> 
> Guido
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
> 


-- 
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/20161230/a3f202b8/attachment.bin