From: dac.override@gmail.com (Dominick Grift)
Date: Mon, 3 Nov 2014 16:16:44 +0100
Subject: [refpolicy] systemd
In-Reply-To: <545795A7.9020705@tresys.com>
References: <54539DFD.6000408@tresys.com> <20141031160000.GA4928@e145.network2>
	<545795A7.9020705@tresys.com>
Message-ID: <20141103151643.GA7676@e145.network2>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, Nov 03, 2014 at 09:48:07AM -0500, Christopher J. PeBenito wrote:
> > 
> > - As for systemd daemons there are, in my view, globally three
> > different kinds (not counting systemd daemon with and without
> > units, or long and short running daemons) - systemd daemons -
> > systemd daemons that are socket activated - systemd daemons that
> > maintain a pid file
> 
> The first and third seem to be the same from the policy perspective,
> other than the third has an extra type and some rules in it's local
> policy.  The second is the new one to the policy.

The difference between regular systemd daemons and systemd daemons that
maintain "systemd pid files" is that systemd needs to be able to read and delete the latters' pid files

So the daemons themselves do not delete them, but systemd does it for them

> 
> 
> > systemd needs to be able to rw, i believe, unix stream socket of
> > target daemon (and probably use fd), maybe more
> 
> For all daemons or just the socket-activated ones?  What is the socket
> for if it's not for socket activation?
> 

I was not accurate:

(allow common_subject systemd_daemon_subject_type (process (signull)))
(call systemd_rw_unix_stream_sockets (systemd_daemon_subject_type))
(call systemd_read_state (systemd_daemon_subject_type))

1. systemd needs to send null signal to all daemons
2. all daemon need to rw (getattr read write ioctl) systemd unix_stream_socket
3. all daemon need to read system state

addiitonally if one decides to split shutdown out of systemd domain then all daemons also need to be able send child terminated signal to shutdown (because shutdown becomes pid 1 on shutdown

> > 
> > There is probably more, that i have overlooked.
> 
> That wouldn't be surprising since the entirety of systemd and it's
> helper tools is massive.

I would probably move systemd utmp out into its own domain since in maintains /run/utmp but probably not feasible for your configuration since init_t is probably already allow to maintain utmp anyways

-- 
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20141103/87ac2915/attachment.bin