From: dac.override@gmail.com (Dominick Grift) Date: Fri, 30 Dec 2016 22:09:36 +0100 Subject: [refpolicy] [PATCH] init: update the initrc_t domain policy In-Reply-To: <1483131974.2893.1.camel@trentalancia.net> References: <1483051782.12123.10.camel@trentalancia.net> <1483128556.3970.14.camel@trentalancia.net> <4ec4885b-4406-0b74-fe06-2a70238cdcb0@gmail.com> <1483129169.3970.21.camel@trentalancia.net> <29718ae9-d4b8-01fa-65c3-cf1d17cf4bbc@gmail.com> <1483131007.2613.1.camel@trentalancia.net> <1483131974.2893.1.camel@trentalancia.net> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 12/30/2016 10:06 PM, Guido Trentalancia via refpolicy wrote: > On Fri, 30/12/2016 at 21.52 +0100, Dominick Grift via refpolicy wrote: >> On 12/30/2016 09:50 PM, Guido Trentalancia via refpolicy wrote: > > [...] > >>>>>>>>>> >>>>>>>>>> +# 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? >>> >>> It's actually the other way around. The comment is correct. >>> >>> The client is eventually running in initrc_t... >>> >>> Such permission is absolutely necessary for the correct functioning >>> of >>> the plymouth terminal interface. >> >> ok then i believe you should instead add: >> >> init_system_domain(plymouth_t, plymouth_exec_t) >> >> or somthing along those lines > > Yes, the above works and is the correct solution, thanks for the tip. > > This leads to a new patch for the plymouth module... So plymouth client stream connects to plymouthd (running with kernel_t because it was already running when the policy got loaded) > > 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/2f76e8e0/attachment.bin