DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C05422089F
Date:   Thu, 8 Nov 2018 00:14:19 +0100
From:   Luis Ressel <aranea@aixah.de>
To:     <selinux-refpolicy@vger.kernel.org>
Subject: init_daemon_domain vs init_spec_daemon_domain
Message-ID: <20181108001419.0d06cd9b@vega.skynet.aixah.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: selinux-refpolicy-owner@vger.kernel.org
Precedence: bulk

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
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