[refpolicy] systemd policy

[dwalsh@redhat.com (Daniel J Walsh)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/14/2014 09:41 AM, Laurent Bigonville wrote:
> Le Tue, 14 Jan 2014 08:34:49 -0500, "Christopher J. PeBenito"
> <cpebenito@tresys.com> a ?crit :
> 
>> 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.
> 
> Well if I'm not wrong, the Fedora policy has added a systemd.pp modules 
> that deals with all the non-PID1 stuffs from systemd (like journald, 
> logind,...). The PID1 related stuffs are still in init module.
> 
>> 
>> I've been dragging my feet on integrating systemd stuff since I don't 
>> have such a good sense of the answers to these questions (and systemd 
>> functions were in flux for a long time.)  A couple months ago I tried 
>> setting up systemd on one of my Gentoo systems, but that didn't go well,
>> since its not well supported (a lot of Gentoo devs reject it's use).  I
>> haven't had a chance to retry on a Fedora system.
>> 
>> That being said, I do want to get support in by the time RHEL7 final goes
>> out.
> 
> Debian is also currently debating about the use of systemd or upstart as
> default init in its next releases.
> 
Most of what is in systemd.te is not related to pid 1.  It is covering all of
the other systemd daemons.

/bin/systemd-notify				--		gen_context(system_u:object_r:systemd_notify_exec_t,s0)
/bin/systemctl					--	gen_context(system_u:object_r:systemd_systemctl_exec_t,s0)
/bin/systemd-tty-ask-password-agent		--	
gen_context(system_u:object_r:systemd_passwd_agent_exec_t,s0)
/bin/systemd-tmpfiles				--	
gen_context(system_u:object_r:systemd_tmpfiles_exec_t,s0)
/usr/bin/systemctl				--
gen_context(system_u:object_r:systemd_systemctl_exec_t,s0)
/usr/bin/systemd-gnome-ask-password-agent	--	
gen_context(system_u:object_r:systemd_passwd_agent_exec_t,s0)
/usr/bin/systemd-notify				--	
gen_context(system_u:object_r:systemd_notify_exec_t,s0)
/usr/bin/systemd-tmpfiles			--	
gen_context(system_u:object_r:systemd_tmpfiles_exec_t,s0)
/usr/bin/systemd-tty-ask-password-agent		--	
gen_context(system_u:object_r:systemd_passwd_agent_exec_t,s0)
/usr/lib/systemd/systemd-hostnamed	--
gen_context(system_u:object_r:systemd_hostnamed_exec_t,s0)
/usr/lib/systemd/systemd-sysctl		--
gen_context(system_u:object_r:systemd_sysctl_exec_t,s0)
/usr/lib/systemd/systemd-timedated	--
gen_context(system_u:object_r:systemd_timedated_exec_t,s0)
/usr/lib/systemd/systemd-logind		--
gen_context(system_u:object_r:systemd_logind_exec_t,s0)
/usr/lib/systemd/systemd-localed	--
gen_context(system_u:object_r:systemd_localed_exec_t,s0)
/usr/lib/systemd/systemd-logger	--
gen_context(system_u:object_r:systemd_logger_exec_t,s0)
/usr/lib/systemd/systemd-tmpfiles --
gen_context(system_u:object_r:systemd_tmpfiles_exec_t,s0)

As well as the unit files, which could be argued do not belong in the init.fc
since they are service specific and systemd specific.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLVT+sACgkQrlYvE4MpobONkQCZAVtUabaN97Mt3iiv0MLv9OMt
nnQAn1jfeihWt5S14V7pbigXKFMyoLws
=0sjs
-----END PGP SIGNATURE-----