From: dwalsh@redhat.com (Daniel J Walsh) Date: Tue, 14 Jan 2014 09:55:39 -0500 Subject: [refpolicy] systemd policy In-Reply-To: <20140114154149.4cdc373f@soldur.bigon.be> 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> <20140114154149.4cdc373f@soldur.bigon.be> Message-ID: <52D54FEB.6090207@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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" > 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-----