DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 297132081C
Subject: Re: init_daemon_domain vs init_spec_daemon_domain
To:     Luis Ressel <aranea@aixah.de>, selinux-refpolicy@vger.kernel.org
References: <20181108001419.0d06cd9b@vega.skynet.aixah.de>
From:   Chris PeBenito <pebenito@ieee.org>
Message-ID: <0664b97f-dd55-51a3-41ef-c3f1f69bc7a9@ieee.org>
Date:   Fri, 9 Nov 2018 19:22:22 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181108001419.0d06cd9b@vega.skynet.aixah.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

On 11/07/2018 06:14 PM, Luis Ressel wrote:
> Hello *,
> 
> I've noticed the init_daemon_domain and init_spec_daemon_domain
> interfaces contain quite a bit of duplicated code. As can be seen from
> the patch I just [two weeks ago, but this mail unfortunately didn't go
> out back then due to a problem on my end] posted, this has already
> caused bugs.
> 
> Ideally, init_daemon_domain should just call init_spec_daemon_domain
> and only add a typetransition statement on top of it. However, this is

I'm inclined to accept a patch that will make this so, regardless of the 
below concerns, since there are no usages in refpolicy.


> currently not possible because those two interfaces differ in some
> aspects:
> 
> * i_d_d grants the daemon nscd_use() permissions, while i_s_d_d
>    doesn't. This is most likely an oversight too.
> 
> * i_d_d permits transitions from initrc_t to the daemon domain, while
>    i_s_d_d permits transitions from init_t. This is thoroughly odd. My
>    expectation was that i_s_d_d would allow transitions from initrc_t
>    too, and as far as I understand the situation, transitions directly
>    from init_t do a daemon domain only happen with systemd.
> 
> * The ifdef(init_systemd) blocks of the two interfaces are very
>    different. Could someone familiar with the systemd policy please
>    comment on this?
> 
> * i_s_d_d obviously grants init_t (and initrc_t if that is added in the
>    future) self:process setexec permissions, while i_d_d doesn't. This
>    makes sense, of course, but if we can fix the three other differences
>    I already mentioned, I don't believe this difference alone should
>    block my proposed change.
> 
> Thanks,
> Luis
> 


-- 
Chris PeBenito