From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 6 Feb 2014 11:32:23 -0500
Subject: [refpolicy] systemd policy
In-Reply-To: <52E66A7C.4050001@redhat.com>
References: <5992094.YlEUt0BCZP@russell.coker.com.au>	<5347508.kSSh66cgIv@russell.coker.com.au>	<52D401D3.5040900@redhat.com>	<3417214.hAyNvCIVsu@russell.coker.com.au>
	<52D53CF9.8030900@tresys.com> <52E66A7C.4050001@redhat.com>
Message-ID: <52F3B917.6050300@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 01/27/14 09:17, Miroslav Grepl wrote:
> On 01/14/2014 02:34 PM, Christopher J. PeBenito wrote:
>> On 01/13/14 18:37, Russell Coker wrote:
>>> On Mon, 13 Jan 2014 10:10:11 Daniel J Walsh wrote:
>>>> Having separate labels on the unit file is not just for "user" domains.   It
>>>> is also for system domains, for example NetworkManager_t is allowed to
>>>> start the following services.
>>> OK.
>>>
>>> I've attached a patch I'm using which defines some unit types and adds fc
>>> entries.  Some of them are missing fc entries, presumably because the daemons
>>> in question didn't have unit files at the time (this policy was taken from
>>> Fedora some time ago).
>>>
>>> I've also added a stub systemd_unit_file() in init.if.  The full systemd policy
>>> patch will have to remove that.  I think this is OK to get the uncontroversial
>>> stuff included in the tree sooner.
>> I don't have a problem with something like this.  The big thing that concerns me about integrating systemd policy is it's structure.  My big question is can we add it onto the init module and toggle rules (similar to init_upstart tunable) reasonably?  Or does is it so different than sysvinit/upstart that it deserves to be implemented as a replacement module for init?  If that's the case, that would surely have some interesting issues (e.g. what to do about initrc_t etc.)  There's also questions about the socket activation and how that fits in.
> How is it complicated? It shows us

I'm not saying the policy is necessarily complicated, but systemd itself is certainly more complicated sysvinit or upstart.

> policy-f20-base.patch
> 
> which we have in Fedora. And yes, initrc_t "goes away" how we know it without systemd.

I'm looking more into this patch, but I have a few initial questions:

* For the huge block of additions at the end of the init_t policy section, are those all related to systemd?

* Would you explain the purpose of each of the added attributes?

* Why does the machine id file need its own type?

On first glance, it seems like we might be able to put all this into an init_systemd tunable, but I'm still looking.  I haven't looked into the separate systemd module that was created.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com