LinuxLists.cc - [refpolicy] systemd policy

[permalink] [raw]

Subject: [refpolicy] systemd policy

Le Sun, 12 Jan 2014 18:06:18 +1100,
Russell Coker <[email protected]> a ?crit :

Hi,

> The below was in the Debian policy tree, it was ported from Fedora
> policy in 2012. What happened to this? Is it needed for systemd?
> It doesn't seem to be in the git repository, has someone devised
> another way of doing this?

I also have some patches for systemd (looks some av have been
removed/changed in the meantime). I could propose them even if there
are very minimal (new av, new security classes, some filecontexts,..),
but nothing like the fedora systemd.pp module.

IIRC, Daniel said that somebody from RH or Fedora (I don't remember
exactly) will look at upstreaming the code they have when they have
time.

Daniel do you know when this will happen? Can I already propose some of
these patches?

Cheers,

Laurent Bigonville

2014-01-13 12:52:56

by Russell Coker

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Sun, 12 Jan 2014 13:18:41 Laurent Bigonville wrote:
> Daniel do you know when this will happen? Can I already propose some of
> these patches?

One thing that would be good to propose first is the labelling of unit files.

Currently in Debian policy we have lots of patches to daemon policy like the
following. If we can agree that each daemon should have it's own unit file
type (which appears to me to have no benefit unless we make a significant
addition to the daemon management functionality) then we can add the patch as-
is. If we are going to add it as-is then the sooner the better, as a patch
that affects lots of files is annoying to maintain.

type apcupsd_unit_file_t;
systemd_unit_file(apcupsd_unit_file_t)

/lib/systemd/system/apcupsd\.service --
gen_context(system_u:object_r:apcupsd_unit_file_t,s0)

It seems to me that the only benefit of per-daemon types is that we can write
policy allowing one user access to manage daemons with several types.

The other possible way of allowing per-user management of daemons managed by
the type of the unit file would be to have a default type for the unit files
(which is easier for .fc files and no change to most daemon policy). Then
whenever we need to delegate some sysadmin rights to a daemon we create a new
type as appropriate and a fcontext rule to label the unit file.

Regardless of when we merge the patches it would be good to get this design
issue sorted out soon.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/

2014-01-13 15:10:11

[permalink] [raw]

Subject: [refpolicy] systemd policy

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

On 01/13/2014 07:52 AM, Russell Coker wrote:
> On Sun, 12 Jan 2014 13:18:41 Laurent Bigonville wrote:
>> Daniel do you know when this will happen? Can I already propose some of
>> these patches?
>
> One thing that would be good to propose first is the labelling of unit
> files.
>
> Currently in Debian policy we have lots of patches to daemon policy like
> the following. If we can agree that each daemon should have it's own unit
> file type (which appears to me to have no benefit unless we make a
> significant addition to the daemon management functionality) then we can
> add the patch as- is. If we are going to add it as-is then the sooner the
> better, as a patch that affects lots of files is annoying to maintain.
>
> type apcupsd_unit_file_t; systemd_unit_file(apcupsd_unit_file_t)
>
> /lib/systemd/system/apcupsd\.service --
> gen_context(system_u:object_r:apcupsd_unit_file_t,s0)
>
> It seems to me that the only benefit of per-daemon types is that we can
> write policy allowing one user access to manage daemons with several
> types.
>
> The other possible way of allowing per-user management of daemons managed
> by the type of the unit file would be to have a default type for the unit
> files (which is easier for .fc files and no change to most daemon policy).
> Then whenever we need to delegate some sysadmin rights to a daemon we
> create a new type as appropriate and a fcontext rule to label the unit
> file.
>
> Regardless of when we merge the patches it would be good to get this design
> issue sorted out soon.
>

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.

sesearch -A -s NetworkManager_t -p start
Found 5 semantic av rules:
allow NetworkManager_t nscd_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t ntpd_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t pppd_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t polipo_unit_file_t : service { start stop status
reload } ;
allow NetworkManager_t dnsmasq_unit_file_t : service { start stop status
reload } ;

I rely on Dominick and Miroslav to get Fedora changes/fixes upstream.

Could you guys take care of getting systemd policy upstream.

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

iEYEARECAAYFAlLUAdMACgkQrlYvE4MpobN05gCeOxOi9JtmMoiCfovdC5np0ed8
1BkAnRzCRpGoIiHTY0E1D7OjHIFPHnp1
=wZz7
-----END PGP SIGNATURE-----

2014-01-13 19:02:33

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Mon, 2014-01-13 at 10:10 -0500, Daniel J Walsh wrote:

> I rely on Dominick and Miroslav to get Fedora changes/fixes upstream.
>
> Could you guys take care of getting systemd policy upstream.
>

We rely on Chris

I recently submitted a small patch just to get the ball rolling but it
did not get any reply.

Other than that, Fedora is also to blame to an extent.

It would help if Fedora also considers things, also for its own benefit.

For example:

Fedora recently remove the init_run_daemon(unconfined_t) from her
policy, while i submitted a solution here on this list that i believe is
sustainable but it was ignore without any comments.

I know Fedora does not have to , or wants to support other init systems
but reference policy does not have that luxury. By going your own way, i
believe you're shutting the door to alternative init systems in Fedora
and you decrease chances of getting stuff up streamed.

Now with every commit Fedora does i have to worry about this because i
know Fedora seems to not care about other scenarios

And then there is the issue that i am taking a bit of distance from the
community. I have to focus on other things unfortunately, but ces't la
vie

_______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

2014-01-13 20:16:34

[permalink] [raw]

Subject: [refpolicy] systemd policy

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

On 01/13/2014 02:02 PM, Dominick Grift wrote:
> On Mon, 2014-01-13 at 10:10 -0500, Daniel J Walsh wrote:
>
>> I rely on Dominick and Miroslav to get Fedora changes/fixes upstream.
>>
>> Could you guys take care of getting systemd policy upstream.
>>
>
> We rely on Chris
>
> I recently submitted a small patch just to get the ball rolling but it did
> not get any reply.
>
> Other than that, Fedora is also to blame to an extent.
>
> It would help if Fedora also considers things, also for its own benefit.
>
> For example:
>
> Fedora recently remove the init_run_daemon(unconfined_t) from her policy,
> while i submitted a solution here on this list that i believe is
> sustainable but it was ignore without any comments.
>
> I know Fedora does not have to , or wants to support other init systems but
> reference policy does not have that luxury. By going your own way, i
> believe you're shutting the door to alternative init systems in Fedora and
> you decrease chances of getting stuff up streamed.
>
> Now with every commit Fedora does i have to worry about this because i know
> Fedora seems to not care about other scenarios
>
> And then there is the issue that i am taking a bit of distance from the
> community. I have to focus on other things unfortunately, but ces't la vie
>
> _______________________________________________
>> refpolicy mailing list refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
Well I would not say we don't care about other init systems, since we still
need to support systemV init scripts. I removed init_run_daemon(unconfined_t)
because it was causing us problems with "Daemons" attempting to run as
unconfined_u:system_r:unconfined_t:s0. We are attempting to tighten security
on confined domains being able to transition to unconfined domains. Currently
we allow unconfined domains to be entered by all file types. We wanted to
remove this since a confined domain that transitions to an unconfined domain.
samba_t -> samba_unconfined_exec_t -> samba_unconfined_t, was only intended to
happen on scripts labeled samba_unconfined_exec_t. But we were not blocking
the entrypoint, so potentially if samba was allowed to do
setexeccon(samba_unconfined_t) it could execute any script to get to it.

After we turned off the entrypoint ability for all confined domains, then we
saw this problem with unconfined_t.

My understanding of the auto transitions for initscripts was supposed to be

unconfined_r:unconfined_t @ *initrc_t -> system_r:initrc_t @httpd_exec_t ->
system_r:httpd_t.

The interface we removed was causing

unconfined_r:unconfined_t @ httpd_exec_t -> system_r:unconfined_t and
generating an entrypoint error.

I don't see why we want unconfined_r role changing to system_r just because it
executed a daemon domain.

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

iEYEARECAAYFAlLUSaIACgkQrlYvE4MpobOCBACgxHyirOGSvJCOlALbYxkdoACh
9/EAn1J/2PYe3SOK9K641BwBxSUt+BGP
=dUCz
-----END PGP SIGNATURE-----

2014-01-13 20:22:12

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Mon, 2014-01-13 at 15:16 -0500, Daniel J Walsh wrote:

> >
> Well I would not say we don't care about other init systems, since we still
> need to support systemV init scripts. I removed init_run_daemon(unconfined_t)
> because it was causing us problems with "Daemons" attempting to run as
> unconfined_u:system_r:unconfined_t:s0. We are attempting to tighten security
> on confined domains being able to transition to unconfined domains.

I suspect you removed it to get rid of the role transition on init
daemon entry files, and i believe my solution deals with that without
the need to remove that interface call.

http://oss.tresys.com/pipermail/refpolicy/2013-December/006740.html

I briefly tested the above patch and it seems to "work"

2014-01-13 21:07:28

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Mon, 2014-01-13 at 21:22 +0100, Dominick Grift wrote:
> On Mon, 2014-01-13 at 15:16 -0500, Daniel J Walsh wrote:
>
> > >
> > Well I would not say we don't care about other init systems, since we still
> > need to support systemV init scripts. I removed init_run_daemon(unconfined_t)
> > because it was causing us problems with "Daemons" attempting to run as
> > unconfined_u:system_r:unconfined_t:s0. We are attempting to tighten security
> > on confined domains being able to transition to unconfined domains.
>
> I suspect you removed it to get rid of the role transition on init
> daemon entry files, and i believe my solution deals with that without
> the need to remove that interface call.
>
> http://oss.tresys.com/pipermail/refpolicy/2013-December/006740.html
>
> I briefly tested the above patch and it seems to "work"
>
>

https://www.youtube.com/watch?v=gqUFSKplehA

Here is a quick demo with some tests to see if above patch works

youtube is also processing a larger video that demonstrates the whole
process from implementing the change to testing it

2014-01-13 23:37:29

by Russell Coker

[permalink] [raw]

Subject: [refpolicy] systemd policy

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.

--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
-------------- next part --------------
Description: Add systemd unit types
Author: Russell Coker <[email protected]>
Last-Update: 2014-01-14

--- a/policy/modules/contrib/alsa.fc
+++ b/policy/modules/contrib/alsa.fc
@@ -24,3 +24,4 @@
/usr/share/alsa/pcm(/.*)? gen_context(system_u:object_r:alsa_etc_rw_t,s0)

/var/lib/alsa(/.*)? gen_context(system_u:object_r:alsa_var_lib_t,s0)
+/lib/systemd/system/alsa-.*\.service -- gen_context(system_u:object_r:alsa_unit_file_t,s0)
--- a/policy/modules/contrib/alsa.te
+++ b/policy/modules/contrib/alsa.te
@@ -27,6 +27,9 @@
type alsa_home_t;
userdom_user_home_content(alsa_home_t)

+type alsa_unit_file_t;
+systemd_unit_file(alsa_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/apache.fc
+++ b/policy/modules/contrib/apache.fc
@@ -26,6 +26,9 @@
/etc/WebCalendar(/.*)? gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)
/etc/zabbix/web(/.*)? gen_context(system_u:object_r:httpd_sys_rw_content_t,s0)

+/lib/systemd/system/httpd.*\.service -- gen_context(system_u:object_r:httpd_unit_file_t,s0)
+/lib/systemd/system/jetty.*\.service -- gen_context(system_u:object_r:httpd_unit_file_t,s0)
+
/opt/.*\.cgi -- gen_context(system_u:object_r:httpd_sys_script_exec_t,s0)
/opt/dirsrv/var/run/dirsrv/dsgw/cookies(/.*)? gen_context(system_u:object_r:httpd_var_run_t,s0)

--- a/policy/modules/contrib/apache.te
+++ b/policy/modules/contrib/apache.te
@@ -286,6 +286,8 @@
type httpd_keytab_t;
files_type(httpd_keytab_t)

+type httpd_unit_file_t;
+systemd_unit_file(httpd_unit_file_t)
type httpd_lock_t;
files_lock_file(httpd_lock_t)

--- a/policy/modules/contrib/apcupsd.fc
+++ b/policy/modules/contrib/apcupsd.fc
@@ -1,5 +1,7 @@
/etc/rc\.d/init\.d/apcupsd -- gen_context(system_u:object_r:apcupsd_initrc_exec_t,s0)

+/lib/systemd/system/apcupsd\.service -- gen_context(system_u:object_r:apcupsd_unit_file_t,s0)
+
/sbin/apcupsd -- gen_context(system_u:object_r:apcupsd_exec_t,s0)

/usr/sbin/apcupsd -- gen_context(system_u:object_r:apcupsd_exec_t,s0)
--- a/policy/modules/contrib/apcupsd.te
+++ b/policy/modules/contrib/apcupsd.te
@@ -24,6 +24,9 @@
type apcupsd_var_run_t;
files_pid_file(apcupsd_var_run_t)

+type apcupsd_unit_file_t;
+systemd_unit_file(apcupsd_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/apm.fc
+++ b/policy/modules/contrib/apm.fc
@@ -17,3 +17,5 @@
/var/run/powersave_socket -s gen_context(system_u:object_r:apmd_var_run_t,s0)

/var/lib/acpi(/.*)? gen_context(system_u:object_r:apmd_var_lib_t,s0)
+
+/lib/systemd/system/apmd\.service -- gen_context(system_u:object_r:apmd_unit_file_t,s0)
--- a/policy/modules/contrib/apm.te
+++ b/policy/modules/contrib/apm.te
@@ -35,6 +35,9 @@
type apmd_var_run_t;
files_pid_file(apmd_var_run_t)

+type apmd_unit_file_t;
+systemd_unit_file(apmd_unit_file_t)
+
########################################
#
# Client local policy
--- a/policy/modules/contrib/arpwatch.fc
+++ b/policy/modules/contrib/arpwatch.fc
@@ -7,3 +7,5 @@
/var/lib/arpwatch(/.*)? gen_context(system_u:object_r:arpwatch_data_t,s0)

/var/run/arpwatch.*\.pid -- gen_context(system_u:object_r:arpwatch_var_run_t,s0)
+
+/lib/systemd/system/arpwatch.service -- gen_context(system_u:object_r:arpwatch_unit_file_t,s0)
--- a/policy/modules/contrib/arpwatch.te
+++ b/policy/modules/contrib/arpwatch.te
@@ -21,6 +21,9 @@
type arpwatch_var_run_t;
files_pid_file(arpwatch_var_run_t)

+type arpwatch_unit_file_t;
+systemd_unit_file(arpwatch_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/automount.fc
+++ b/policy/modules/contrib/automount.fc
@@ -6,3 +6,5 @@
/var/lock/subsys/autofs -- gen_context(system_u:object_r:automount_lock_t,s0)

/var/run/autofs.* gen_context(system_u:object_r:automount_var_run_t,s0)
+
+/lib/systemd/system/autofs\.service -- gen_context(system_u:object_r:automount_unit_file_t,s0)
--- a/policy/modules/contrib/automount.te
+++ b/policy/modules/contrib/automount.te
@@ -25,6 +25,9 @@
type automount_var_run_t;
files_pid_file(automount_var_run_t)

+type automount_unit_file_t;
+systemd_unit_file(automount_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/avahi.fc
+++ b/policy/modules/contrib/avahi.fc
@@ -7,3 +7,5 @@
/var/run/avahi-daemon(/.*)? gen_context(system_u:object_r:avahi_var_run_t,s0)

/var/lib/avahi-autoipd(/.*)? gen_context(system_u:object_r:avahi_var_lib_t,s0)
+
+/lib/systemd/system/avahi.*\.service -- gen_context(system_u:object_r:avahi_unit_file_t,s0)
--- a/policy/modules/contrib/avahi.te
+++ b/policy/modules/contrib/avahi.te
@@ -18,6 +18,9 @@
type avahi_var_run_t;
files_pid_file(avahi_var_run_t)

+type avahi_unit_file_t;
+systemd_unit_file(avahi_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/bind.fc
+++ b/policy/modules/contrib/bind.fc
@@ -14,6 +14,10 @@
/etc/unbound(/.*)? gen_context(system_u:object_r:named_conf_t,s0)
/etc/unbound/.*\.key -- gen_context(system_u:object_r:dnssec_t,s0)

+/lib/systemd/system/unbound.service -- gen_context(system_u:object_r:named_unit_file_t,s0)
+/lib/systemd/system/unbound-keygen.service -- gen_context(system_u:object_r:named_unit_file_t,s0)
+/lib/systemd/system/named.service -- gen_context(system_u:object_r:named_unit_file_t,s0)
+
/usr/sbin/lwresd -- gen_context(system_u:object_r:named_exec_t,s0)
/usr/sbin/named -- gen_context(system_u:object_r:named_exec_t,s0)
/usr/sbin/named-checkconf -- gen_context(system_u:object_r:named_checkconf_exec_t,s0)
--- a/policy/modules/contrib/bind.te
+++ b/policy/modules/contrib/bind.te
@@ -47,6 +47,9 @@
type named_keytab_t;
files_type(named_keytab_t)

+type named_unit_file_t;
+systemd_unit_file(named_unit_file_t)
+
type named_log_t;
logging_log_file(named_log_t)

--- a/policy/modules/contrib/bluetooth.fc
+++ b/policy/modules/contrib/bluetooth.fc
@@ -22,3 +22,5 @@

/var/run/bluetoothd_address -- gen_context(system_u:object_r:bluetooth_var_run_t,s0)
/var/run/sdp -s gen_context(system_u:object_r:bluetooth_var_run_t,s0)
+
+/lib/systemd/system/bluetooth\.service -- gen_context(system_u:object_r:bluetooth_unit_file_t,s0)
--- a/policy/modules/contrib/bluetooth.te
+++ b/policy/modules/contrib/bluetooth.te
@@ -49,6 +49,9 @@
type bluetooth_var_run_t;
files_pid_file(bluetooth_var_run_t)

+type bluetooth_unit_file_t;
+systemd_unit_file(bluetooth_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/clamav.fc
+++ b/policy/modules/contrib/clamav.fc
@@ -24,3 +24,7 @@
/var/run/clamd.* gen_context(system_u:object_r:clamd_var_run_t,s0)

/var/spool/amavisd/clamd\.sock -s gen_context(system_u:object_r:clamd_var_run_t,s0)
+
+/lib/systemd/system/clamd at scan\.service -- gen_context(system_u:object_r:clamd_unit_file_t,s0)
+/lib/systemd/system/clamd@\.service -- gen_context(system_u:object_r:clamd_unit_file_t,s0)
+/lib/systemd/system/clamd\.clamav\.service -- gen_context(system_u:object_r:clamd_unit_file_t,s0)
--- a/policy/modules/contrib/clamav.te
+++ b/policy/modules/contrib/clamav.te
@@ -38,6 +38,9 @@
type clamd_initrc_exec_t;
init_script_file(clamd_initrc_exec_t)

+type clamd_unit_file_t;
+systemd_unit_file(clamd_unit_file_t)
+
type clamd_tmp_t;
files_tmp_file(clamd_tmp_t)

--- a/policy/modules/contrib/consolekit.fc
+++ b/policy/modules/contrib/consolekit.fc
@@ -1,3 +1,5 @@
+/lib/systemd/system/console-kit.*\.service -- gen_context(system_u:object_r:consolekit_unit_file_t,s0)
+
/usr/sbin/console-kit-daemon -- gen_context(system_u:object_r:consolekit_exec_t,s0)

/var/log/ConsoleKit(/.*)? gen_context(system_u:object_r:consolekit_log_t,s0)
--- a/policy/modules/contrib/consolekit.te
+++ b/policy/modules/contrib/consolekit.te
@@ -19,6 +19,9 @@
files_pid_file(consolekit_var_run_t)
init_daemon_run_dir(consolekit_var_run_t, "ConsoleKit")

+type consolekit_unit_file_t;
+systemd_unit_file(consolekit_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/cron.fc
+++ b/policy/modules/contrib/cron.fc
@@ -64,3 +64,6 @@
/var/spool/cron/lastrun/[^/]* -- <<none>>
/var/spool/cron/tabs -d gen_context(system_u:object_r:cron_spool_t,s0)
')
+
+/lib/systemd/system/atd\.service -- gen_context(system_u:object_r:crond_unit_file_t,s0)
+/lib/systemd/system/crond\.service -- gen_context(system_u:object_r:crond_unit_file_t,s0)
--- a/policy/modules/contrib/cron.te
+++ b/policy/modules/contrib/cron.te
@@ -71,6 +71,9 @@
type crond_initrc_exec_t;
init_script_file(crond_initrc_exec_t)

+type crond_unit_file_t;
+systemd_unit_file(crond_unit_file_t)
+
type crond_tmp_t;
files_tmp_file(crond_tmp_t)
files_poly_parent(crond_tmp_t)
--- a/policy/modules/contrib/cups.fc
+++ b/policy/modules/contrib/cups.fc
@@ -75,3 +75,5 @@
/var/run/ptal-mlcd(/.*)? gen_context(system_u:object_r:ptal_var_run_t,s0)
/var/run/udev-configure-printer(/.*)? gen_context(system_u:object_r:cupsd_config_var_run_t,s0)
/var/turboprint(/.*)? gen_context(system_u:object_r:cupsd_var_run_t,s0)
+
+/lib/systemd/system/cups\.service -- gen_context(system_u:object_r:cupsd_unit_file_t,s0)
--- a/policy/modules/contrib/cups.te
+++ b/policy/modules/contrib/cups.te
@@ -62,6 +62,9 @@
init_daemon_run_dir(cupsd_var_run_t, "cups")
mls_trusted_object(cupsd_var_run_t)

+type cupsd_unit_file_t;
+systemd_unit_file(cupsd_unit_file_t)
+
type hplip_t;
type hplip_exec_t;
init_daemon_domain(hplip_t, hplip_exec_t)
--- a/policy/modules/contrib/dhcp.fc
+++ b/policy/modules/contrib/dhcp.fc
@@ -6,3 +6,4 @@
/var/lib/dhcp(3)?/dhcpd\.leases.* -- gen_context(system_u:object_r:dhcpd_state_t,s0)

/var/run/dhcpd(6)?\.pid -- gen_context(system_u:object_r:dhcpd_var_run_t,s0)
+/lib/systemd/system/dhcpcd.* -- gen_context(system_u:object_r:dhcpd_unit_file_t,s0)
--- a/policy/modules/contrib/dhcp.te
+++ b/policy/modules/contrib/dhcp.te
@@ -20,6 +20,9 @@
type dhcpd_initrc_exec_t;
init_script_file(dhcpd_initrc_exec_t)

+type dhcpd_unit_file_t;
+systemd_unit_file(dhcpd_unit_file_t)
+
type dhcpd_state_t;
files_type(dhcpd_state_t)

--- a/policy/modules/contrib/dnsmasq.fc
+++ b/policy/modules/contrib/dnsmasq.fc
@@ -12,3 +12,4 @@

/var/run/dnsmasq.* -- gen_context(system_u:object_r:dnsmasq_var_run_t,s0)
/var/run/libvirt/network(/.*)? gen_context(system_u:object_r:dnsmasq_var_run_t,s0)
+/lib/systemd/system/dnsmasq.* -- gen_context(system_u:object_r:dnsmasq_unit_file_t,s0)
--- a/policy/modules/contrib/dnsmasq.te
+++ b/policy/modules/contrib/dnsmasq.te
@@ -24,6 +24,9 @@
type dnsmasq_var_run_t;
files_pid_file(dnsmasq_var_run_t)

+type dnsmasq_unit_file_t;
+systemd_unit_file(dnsmasq_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/contrib/ftp.fc
+++ b/policy/modules/contrib/ftp.fc
@@ -26,3 +26,6 @@
/var/log/vsftpd.* -- gen_context(system_u:object_r:xferlog_t,s0)
/var/log/xferlog.* -- gen_context(system_u:object_r:xferlog_t,s0)
/var/log/xferreport.* -- gen_context(system_u:object_r:xferlog_t,s0)
+
+/lib/systemd/system/vsftpd.* -- gen_context(system_u:object_r:iptables_unit_file_t,s0)
+/lib/systemd/system/proftpd.* -- gen_context(system_u:object_r:iptables_unit_file_t,s0)
--- a/policy/modules/contrib/ftp.te
+++ b/policy/modules/contrib/ftp.te
@@ -127,6 +127,9 @@
type ftpd_keytab_t;
files_type(ftpd_keytab_t)

+type ftpd_unit_file_t;
+systemd_unit_file(ftpd_unit_file_t)
+
type ftpd_lock_t;
files_lock_file(ftpd_lock_t)

--- a/policy/modules/contrib/kdump.fc
+++ b/policy/modules/contrib/kdump.fc
@@ -11,3 +11,5 @@

/usr/sbin/kdump -- gen_context(system_u:object_r:kdump_exec_t,s0)
/usr/sbin/kexec -- gen_context(system_u:object_r:kdump_exec_t,s0)
+
+/lib/systemd/system/kdump.service -- gen_context(system_u:object_r:iptables_unit_file_t,s0)
--- a/policy/modules/contrib/kdump.te
+++ b/policy/modules/contrib/kdump.te
@@ -23,6 +23,9 @@
type kdumpctl_tmp_t;
files_tmp_file(kdumpctl_tmp_t)

+type kdump_unit_file_t;
+systemd_unit_file(kdump_unit_file_t)
+
#####################################
#
# Local policy
--- a/policy/modules/contrib/ldap.fc
+++ b/policy/modules/contrib/ldap.fc
@@ -27,3 +27,5 @@
/var/run/slapd.* -s gen_context(system_u:object_r:slapd_var_run_t,s0)
/var/run/slapd\.args -- gen_context(system_u:object_r:slapd_var_run_t,s0)
/var/run/slapd\.pid -- gen_context(system_u:object_r:slapd_var_run_t,s0)
+
+/lib/systemd/system/slapd.* -- gen_context(system_u:object_r:slapd_unit_file_t,s0)
--- a/policy/modules/contrib/ldap.te
+++ b/policy/modules/contrib/ldap.te
@@ -24,6 +24,9 @@
type slapd_keytab_t;
files_type(slapd_keytab_t)

+type slapd_unit_file_t;
+systemd_unit_file(slapd_unit_file_t)
+
type slapd_lock_t;
files_lock_file(slapd_lock_t)

--- a/policy/modules/contrib/mysql.fc
+++ b/policy/modules/contrib/mysql.fc
@@ -25,3 +25,5 @@
/var/run/mysqld.* gen_context(system_u:object_r:mysqld_var_run_t,s0)
/var/run/mysqlmanager.* -- gen_context(system_u:object_r:mysqlmanagerd_var_run_t,s0)
/var/run/mysqld/mysqlmanager.* -- gen_context(system_u:object_r:mysqlmanagerd_var_run_t,s0)
+
+/lib/systemd/system/mysqld\.service -- gen_context(system_u:object_r:mysqld_unit_file_t,s0)
--- a/policy/modules/contrib/mysql.te
+++ b/policy/modules/contrib/mysql.te
@@ -38,6 +38,9 @@
type mysqld_home_t;
userdom_user_home_content(mysqld_home_t)

+type mysqld_unit_file_t;
+systemd_unit_file(mysqld_unit_file_t)
+
type mysqld_initrc_exec_t;
init_script_file(mysqld_initrc_exec_t)

--- a/policy/modules/contrib/networkmanager.fc
+++ b/policy/modules/contrib/networkmanager.fc
@@ -1,3 +1,4 @@
+/lib/systemd/system/NetworkManager\.service -- gen_context(system_u:object_r:NetworkManager_unit_file_t,s0)
/etc/rc\.d/init\.d/wicd -- gen_context(system_u:object_r:NetworkManager_initrc_exec_t,s0)

/etc/NetworkManager(/.*)? gen_context(system_u:object_r:NetworkManager_etc_t,s0)
--- a/policy/modules/contrib/networkmanager.te
+++ b/policy/modules/contrib/networkmanager.te
@@ -18,6 +18,9 @@
type NetworkManager_initrc_exec_t;
init_script_file(NetworkManager_initrc_exec_t)

+type NetworkManager_unit_file_t;
+systemd_unit_file(NetworkManager_unit_file_t)
+
type NetworkManager_log_t;
logging_log_file(NetworkManager_log_t)

--- a/policy/modules/contrib/nis.fc
+++ b/policy/modules/contrib/nis.fc
@@ -20,3 +20,8 @@
/var/run/ypbind.* -- gen_context(system_u:object_r:ypbind_var_run_t,s0)
/var/run/ypserv.* -- gen_context(system_u:object_r:ypserv_var_run_t,s0)
/var/run/yppass.* -- gen_context(system_u:object_r:yppasswdd_var_run_t,s0)
+
+/lib/systemd/system/ypbind\.service -- gen_context(system_u:object_r:ypbind_unit_file_t,s0)
+/lib/systemd/system/ypserv\.service -- gen_context(system_u:object_r:nis_unit_file_t,s0)
+/lib/systemd/system/yppasswdd\.service -- gen_context(system_u:object_r:nis_unit_file_t,s0)
+/lib/systemd/system/ypxfrd\.service -- gen_context(system_u:object_r:nis_unit_file_t,s0)
--- a/policy/modules/contrib/nis.te
+++ b/policy/modules/contrib/nis.te
@@ -27,6 +27,9 @@
type ypbind_var_run_t;
files_pid_file(ypbind_var_run_t)

+type ypbind_unit_file_t;
+systemd_unit_file(ypbind_unit_file_t)
+
type yppasswdd_t;
type yppasswdd_exec_t;
init_daemon_domain(yppasswdd_t, yppasswdd_exec_t)
@@ -55,6 +58,9 @@
type ypxfr_var_run_t;
files_pid_file(ypxfr_var_run_t)

+type nis_unit_file_t;
+systemd_unit_file(nis_unit_file_t)
+
########################################
#
# ypbind local policy
--- a/policy/modules/contrib/nscd.te
+++ b/policy/modules/contrib/nscd.te
@@ -31,6 +31,9 @@
type nscd_initrc_exec_t;
init_script_file(nscd_initrc_exec_t)

+type nscd_unit_file_t;
+systemd_unit_file(nscd_unit_file_t)
+
type nscd_log_t;
logging_log_file(nscd_log_t)

--- a/policy/modules/contrib/ntp.fc
+++ b/policy/modules/contrib/ntp.fc
@@ -21,3 +21,7 @@
/var/log/xntpd.* -- gen_context(system_u:object_r:ntpd_log_t,s0)

/var/run/ntpd\.pid -- gen_context(system_u:object_r:ntpd_var_run_t,s0)
+
+/lib/systemd/system/ntpd\.service -- gen_context(system_u:object_r:ntpd_unit_file_t,s0)
+
+/usr/lib/systemd/system/ntpd\.service -- gen_context(system_u:object_r:ntpd_unit_file_t,s0)
--- a/policy/modules/contrib/ntp.te
+++ b/policy/modules/contrib/ntp.te
@@ -21,6 +21,9 @@
type ntp_conf_t;
files_config_file(ntp_conf_t)

+type ntpd_unit_file_t;
+systemd_unit_file(ntpd_unit_file_t)
+
type ntpd_key_t;
files_type(ntpd_key_t)

--- a/policy/modules/contrib/ppp.fc
+++ b/policy/modules/contrib/ppp.fc
@@ -28,3 +28,5 @@
/var/run/pppd[0-9]*\.tdb -- gen_context(system_u:object_r:pppd_var_run_t,s0)
/var/run/ppp(/.*)? gen_context(system_u:object_r:pppd_var_run_t,s0)
/var/run/pptp(/.*)? gen_context(system_u:object_r:pptp_var_run_t,s0)
+
+/lib/systemd/system/ppp.* -- gen_context(system_u:object_r:pppd_unit_file_t,s0)
--- a/policy/modules/contrib/ppp.te
+++ b/policy/modules/contrib/ppp.te
@@ -41,6 +41,9 @@
type pppd_initrc_exec_t alias pppd_script_exec_t;
init_script_file(pppd_initrc_exec_t)

+type pppd_unit_file_t;
+systemd_unit_file(pppd_unit_file_t)
+
type pppd_secret_t;
files_type(pppd_secret_t)

--- a/policy/modules/contrib/rpc.fc
+++ b/policy/modules/contrib/rpc.fc
@@ -20,3 +20,6 @@

/var/run/rpc\.statd(/.*)? gen_context(system_u:object_r:rpcd_var_run_t,s0)
/var/run/rpc\.statd\.pid -- gen_context(system_u:object_r:rpcd_var_run_t,s0)
+
+/lib/systemd/system/nfs.* -- gen_context(system_u:object_r:nfsd_unit_file_t,s0)
+/lib/systemd/system/rpc.* -- gen_context(system_u:object_r:rpcd_unit_file_t,s0)
--- a/policy/modules/contrib/rpc.te
+++ b/policy/modules/contrib/rpc.te
@@ -44,11 +44,17 @@
type rpcd_initrc_exec_t;
init_script_file(rpcd_initrc_exec_t)

+type rpcd_unit_file_t;
+systemd_unit_file(rpcd_unit_file_t)
+
rpc_domain_template(nfsd)

type nfsd_initrc_exec_t;
init_script_file(nfsd_initrc_exec_t)

+type nfsd_unit_file_t;
+systemd_unit_file(nfsd_unit_file_t)
+
type nfsd_rw_t;
files_type(nfsd_rw_t)

--- a/policy/modules/contrib/samba.fc
+++ b/policy/modules/contrib/samba.fc
@@ -8,6 +8,8 @@
/etc/samba/smbpasswd -- gen_context(system_u:object_r:samba_secrets_t,s0)
/etc/samba(/.*)? gen_context(system_u:object_r:samba_etc_t,s0)

+/lib/systemd/system/smb.service -- gen_context(system_u:object_r:samba_unit_file_t,s0)
+
/usr/bin/net -- gen_context(system_u:object_r:samba_net_exec_t,s0)
/usr/bin/ntlm_auth -- gen_context(system_u:object_r:winbind_helper_exec_t,s0)
/usr/bin/smbcontrol -- gen_context(system_u:object_r:smbcontrol_exec_t,s0)
--- a/policy/modules/contrib/samba.te
+++ b/policy/modules/contrib/samba.te
@@ -113,6 +113,9 @@
type samba_initrc_exec_t;
init_script_file(samba_initrc_exec_t)

+type samba_unit_file_t;
+systemd_unit_file(samba_unit_file_t)
+
type samba_log_t;
logging_log_file(samba_log_t)

--- a/policy/modules/contrib/tor.fc
+++ b/policy/modules/contrib/tor.fc
@@ -5,6 +5,8 @@
/usr/bin/tor -- gen_context(system_u:object_r:tor_exec_t,s0)
/usr/sbin/tor -- gen_context(system_u:object_r:tor_exec_t,s0)

+/lib/systemd/system/tor\.service -- gen_context(system_u:object_r:tor_unit_file_t,s0)
+
/var/lib/tor(/.*)? gen_context(system_u:object_r:tor_var_lib_t,s0)
/var/lib/tor-data(/.*)? gen_context(system_u:object_r:tor_var_lib_t,s0)

--- a/policy/modules/contrib/tor.te
+++ b/policy/modules/contrib/tor.te
@@ -33,6 +33,9 @@
files_pid_file(tor_var_run_t)
init_daemon_run_dir(tor_var_run_t, "tor")

+type tor_unit_file_t;
+systemd_unit_file(tor_unit_file_t)
+
########################################
#
# Local policy
--- a/policy/modules/system/iptables.fc
+++ b/policy/modules/system/iptables.fc
@@ -3,6 +3,9 @@
/etc/sysconfig/ip6?tables.* -- gen_context(system_u:object_r:iptables_conf_t,s0)
/etc/sysconfig/system-config-firewall.* -- gen_context(system_u:object_r:iptables_conf_t,s0)

+/lib/systemd/system/iptables.service -- gen_context(system_u:object_r:iptables_unit_file_t,s0)
+/lib/systemd/system/ip6tables.service -- gen_context(system_u:object_r:iptables_unit_file_t,s0)
+
/sbin/ebtables -- gen_context(system_u:object_r:iptables_exec_t,s0)
/sbin/ebtables-restore -- gen_context(system_u:object_r:iptables_exec_t,s0)
/sbin/ipchains.* -- gen_context(system_u:object_r:iptables_exec_t,s0)
--- a/policy/modules/system/iptables.te
+++ b/policy/modules/system/iptables.te
@@ -25,6 +25,9 @@
type iptables_var_run_t;
files_pid_file(iptables_var_run_t)

+type iptables_unit_file_t;
+systemd_unit_file(iptables_unit_file_t)
+
########################################
#
# Iptables local policy
--- a/policy/modules/system/logging.fc
+++ b/policy/modules/system/logging.fc
@@ -6,6 +6,8 @@
/etc/rc\.d/init\.d/auditd -- gen_context(system_u:object_r:auditd_initrc_exec_t,s0)
/etc/rc\.d/init\.d/rsyslog -- gen_context(system_u:object_r:syslogd_initrc_exec_t,s0)

+/lib/systemd/system/auditd\.service -- gen_context(system_u:object_r:auditd_unit_file_t,s0)
+
/sbin/audispd -- gen_context(system_u:object_r:audisp_exec_t,s0)
/sbin/audisp-remote -- gen_context(system_u:object_r:audisp_remote_exec_t,s0)
/sbin/auditctl -- gen_context(system_u:object_r:auditctl_exec_t,s0)
--- a/policy/modules/system/logging.te
+++ b/policy/modules/system/logging.te
@@ -33,6 +33,9 @@
type auditd_var_run_t;
files_pid_file(auditd_var_run_t)

+type auditd_unit_file_t;
+systemd_unit_file(auditd_unit_file_t)
+
type audisp_t;
type audisp_exec_t;
init_system_domain(audisp_t, audisp_exec_t)
--- a/policy/flask/access_vectors
+++ b/policy/flask/access_vectors
@@ -389,10 +389,14 @@
class system
{
ipc_info
- syslog_read
+ syslog_read
syslog_mod
syslog_console
module_request
+ halt
+ reboot
+ status
+ undefined
}

#
@@ -865,3 +869,20 @@
implement
execute
}
+
+class service
+{
+ start
+ stop
+ status
+ reload
+ kill
+ load
+ enable
+ disable
+}
+
+class proxy
+{
+ read
+}
--- a/policy/flask/security_classes
+++ b/policy/flask/security_classes
@@ -131,4 +131,10 @@
class db_sequence # userspace
class db_language # userspace

+# systemd services
+class service
+
+# gssd services
+class proxy
+
# FLASK
--- a/policy/modules/system/init.if
+++ b/policy/modules/system/init.if
@@ -1844,3 +1844,17 @@
')
corenet_udp_recvfrom_labeled($1, daemon)
')
+
+#######################################
+## <summary>
+## Create a file type used for systemd unit files.
+## </summary>
+## <param name="script_file">
+## <summary>
+## Type to be used for an unit file.
+## </summary>
+## </param>
+#
+interface(`systemd_unit_file',`
+ files_type($1)
+')

2014-01-14 09:46:23

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Tue, 2014-01-14 at 10:37 +1100, 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.

Please send your patches in-line so that we can easily comment on them.

Here is one thing that can be improved in your patch:

This is how its supposed to be:

/lib/systemd/system/alsa-.*\.service --
gen_context(system_u:object_r:alsa_unit_file_t,s0)

These are not optimal and its inconsistent with above:

/lib/systemd/system/named.service --
gen_context(system_u:object_r:named_unit_file_t,s0)

You see:

# grep system /etc/selinux/targeted/contexts/files/*.subs_dist
/run/systemd/system /usr/lib/systemd/system
/run/systemd/generator /usr/lib/systemd/system
/etc/systemd/system /usr/lib/systemd/system

So /etc/systemd/system is equivalent to /usr/lib/systemd/system

Now consider me having a name daemon dns server on each of my two
networks. Then i need a instance for each. So i create two "named" unit
files in /etc/systemd/system/named_{network1,network2}.service

So we can use the .* wildcard to catch these?

So i would suggest we create file contexts for unit files with .*
consistently to catch prefixed service files

2014-01-14 09:58:44

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Tue, 2014-01-14 at 10:46 +0100, Dominick Grift wrote:
> On Tue, 2014-01-14 at 10:37 +1100, 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.
>
> Please send your patches in-line so that we can easily comment on them.
>
> Here is one thing that can be improved in your patch:
>
> This is how its supposed to be:
>
> /lib/systemd/system/alsa-.*\.service --
> gen_context(system_u:object_r:alsa_unit_file_t,s0)
>
> These are not optimal and its inconsistent with above:
>
> /lib/systemd/system/named.service --
> gen_context(system_u:object_r:named_unit_file_t,s0)
>
> You see:
>
> # grep system /etc/selinux/targeted/contexts/files/*.subs_dist
> /run/systemd/system /usr/lib/systemd/system
> /run/systemd/generator /usr/lib/systemd/system
> /etc/systemd/system /usr/lib/systemd/system
>
> So /etc/systemd/system is equivalent to /usr/lib/systemd/system
>
> Now consider me having a name daemon dns server on each of my two
> networks. Then i need a instance for each. So i create two "named" unit
> files in /etc/systemd/system/named_{network1,network2}.service
>
> So we can use the .* wildcard to catch these?
>
> So i would suggest we create file contexts for unit files with .*
> consistently to catch prefixed service files
>
>

Maybe not the best example but what i am saying is that i think for
example this:

/lib/systemd/system/named.service --
gen_context(system_u:object_r:named_unit_file_t,s0)

should be:

/lib/systemd/system/named.*\.service --
gen_context(system_u:object_r:named_unit_file_t,s0)

and that this should be implemented consistently for all unit file
context specifications where possible

even that may not be optimal but i think it makes more sense

2014-01-14 10:12:02

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Tue, 2014-01-14 at 10:37 +1100, Russell Coker wrote:
> --- a/policy/flask/access_vectors
> +++ b/policy/flask/access_vectors
> @@ -389,10 +389,14 @@
> class system
> {
> ipc_info
> - syslog_read
> + syslog_read
> syslog_mod
> syslog_console
> module_request
> + halt
> + reboot
> + status
> + undefined
> }
>

I am not sure if these should be added but i might be wrong

These seem like systemd OM av permissions
system is kernel OM security class

Not sure whether, if my assumptions are correct, it makes sense to add
user space av permissions to kernel security classes

2014-01-14 11:24:24

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Mon, 2014-01-13 at 15:16 -0500, Daniel J Walsh wrote:
> On 01/13/2014 02:02 PM, Dominick Grift wrote:
> > On Mon, 2014-01-13 at 10:10 -0500, Daniel J Walsh wrote:
> >
> >> I rely on Dominick and Miroslav to get Fedora changes/fixes upstream.
> >>
> >> Could you guys take care of getting systemd policy upstream.
> >>
> >
> > We rely on Chris
> >
> > I recently submitted a small patch just to get the ball rolling but it did
> > not get any reply.
> >
> > Other than that, Fedora is also to blame to an extent.
> >
> > It would help if Fedora also considers things, also for its own benefit.
> >
> > For example:
> >
> > Fedora recently remove the init_run_daemon(unconfined_t) from her policy,
> > while i submitted a solution here on this list that i believe is
> > sustainable but it was ignore without any comments.
> >
> > I know Fedora does not have to , or wants to support other init systems but
> > reference policy does not have that luxury. By going your own way, i
> > believe you're shutting the door to alternative init systems in Fedora and
> > you decrease chances of getting stuff up streamed.
> >
> > Now with every commit Fedora does i have to worry about this because i know
> > Fedora seems to not care about other scenarios
> >
> > And then there is the issue that i am taking a bit of distance from the
> > community. I have to focus on other things unfortunately, but ces't la vie
> >
> > _______________________________________________
> >> refpolicy mailing list refpolicy at oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> >
> Well I would not say we don't care about other init systems, since we still
> need to support systemV init scripts. I removed init_run_daemon(unconfined_t)
> because it was causing us problems with "Daemons" attempting to run as
> unconfined_u:system_r:unconfined_t:s0. We are attempting to tighten security
> on confined domains being able to transition to unconfined domains. Currently
> we allow unconfined domains to be entered by all file types. We wanted to
> remove this since a confined domain that transitions to an unconfined domain.
> samba_t -> samba_unconfined_exec_t -> samba_unconfined_t, was only intended to
> happen on scripts labeled samba_unconfined_exec_t. But we were not blocking
> the entrypoint, so potentially if samba was allowed to do
> setexeccon(samba_unconfined_t) it could execute any script to get to it.
>
> After we turned off the entrypoint ability for all confined domains, then we
> saw this problem with unconfined_t.
>
> My understanding of the auto transitions for initscripts was supposed to be
>
> unconfined_r:unconfined_t @ *initrc_t -> system_r:initrc_t @httpd_exec_t ->
> system_r:httpd_t.
>
> The interface we removed was causing
>
> unconfined_r:unconfined_t @ httpd_exec_t -> system_r:unconfined_t and
> generating an entrypoint error.
>
> I don't see why we want unconfined_r role changing to system_r just because it
> executed a daemon domain.
>
>

Let me try this another way:

Your solution "solves" the issue only for unconfined_t.

My solution: 1. fixes a broken interface, 2. "solves" the issue for
sysadm_t as well as for unconfined_t. 3. Does not break direct_initrc
(or at least should work with my other patches titled "make
direct_initrc apply to unconfined_t", if they are applied fully)

2014-01-14 12:22:05

[permalink] [raw]

Subject: [refpolicy] systemd policy

Le Tue, 14 Jan 2014 10:37:29 +1100,
Russell Coker <[email protected]> a ?crit :

[...]
> --- a/policy/flask/access_vectors
> +++ b/policy/flask/access_vectors
> @@ -389,10 +389,14 @@
> class system
> {
> ipc_info
> - syslog_read
> + syslog_read
> syslog_mod
> syslog_console
> module_request
> + halt
> + reboot
> + status
> + undefined
> }

I don't know from where this "undefined" is coming from. I looked
sometimes ago in the systemd source code and undefined was not used.

And it's missing "enable" and "disable".

You can grep "SELINUX_ACCESS_CHECK" in the code.

>
> #
> @@ -865,3 +869,20 @@
> implement
> execute
> }
> +
> +class service
> +{
> + start
> + stop
> + status
> + reload
> + kill
> + load
> + enable
> + disable
> +}

Here again, I don't think all these AV are in use.

You can grep "SELINUX_UNIT_ACCESS_CHECK" in the code, only start, stop
status and reload are used here I think.

> +class proxy
> +{
> + read
> +}
> --- a/policy/flask/security_classes
> +++ b/policy/flask/security_classes
> @@ -131,4 +131,10 @@
> class db_sequence # userspace
> class db_language # userspace
>
> +# systemd services
> +class service
> +
> +# gssd services
> +class proxy
> +

I'm not sure that the "proxy" class should be part of the same patch
this is not needed for systemd.

[...]

Cheers,

Laurent Bigonville

2014-01-14 12:35:12

[permalink] [raw]

Subject: [refpolicy] systemd policy

Le Tue, 14 Jan 2014 10:46:23 +0100,
Dominick Grift <[email protected]> a ?crit :

> On Tue, 2014-01-14 at 10:37 +1100, 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.
>
> Please send your patches in-line so that we can easily comment on
> them.
>
> Here is one thing that can be improved in your patch:
>
> This is how its supposed to be:
>
> /lib/systemd/system/alsa-.*\.service --
> gen_context(system_u:object_r:alsa_unit_file_t,s0)
>
> These are not optimal and its inconsistent with above:
>
> /lib/systemd/system/named.service --
> gen_context(system_u:object_r:named_unit_file_t,s0)
>
> You see:
>
> # grep system /etc/selinux/targeted/contexts/files/*.subs_dist
> /run/systemd/system /usr/lib/systemd/system
> /run/systemd/generator /usr/lib/systemd/system
> /etc/systemd/system /usr/lib/systemd/system
>
> So /etc/systemd/system is equivalent to /usr/lib/systemd/system

Here come a question, are we using the Fedora or the Debian paths for
systemd? In Fedora everything is in /usr/lib/systemd, in Debian
it's /lib/systemd. This should be standardized, and then we can add an
equivalence for the others. I personally don't care, as most of the
patches will come from Fedora, I guess we could use the Fedora way.

2014-01-14 13:03:04

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Tue, 2014-01-14 at 13:35 +0100, Laurent Bigonville wrote:
> Le Tue, 14 Jan 2014 10:46:23 +0100,
> Dominick Grift <[email protected]> a ?crit :
>
> > On Tue, 2014-01-14 at 10:37 +1100, 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.
> >
> > Please send your patches in-line so that we can easily comment on
> > them.
> >
> > Here is one thing that can be improved in your patch:
> >
> > This is how its supposed to be:
> >
> > /lib/systemd/system/alsa-.*\.service --
> > gen_context(system_u:object_r:alsa_unit_file_t,s0)
> >
> > These are not optimal and its inconsistent with above:
> >
> > /lib/systemd/system/named.service --
> > gen_context(system_u:object_r:named_unit_file_t,s0)
> >
> > You see:
> >
> > # grep system /etc/selinux/targeted/contexts/files/*.subs_dist
> > /run/systemd/system /usr/lib/systemd/system
> > /run/systemd/generator /usr/lib/systemd/system
> > /etc/systemd/system /usr/lib/systemd/system
> >
> > So /etc/systemd/system is equivalent to /usr/lib/systemd/system
>
> Here come a question, are we using the Fedora or the Debian paths for
> systemd? In Fedora everything is in /usr/lib/systemd, in Debian
> it's /lib/systemd. This should be standardized, and then we can add an
> equivalence for the others. I personally don't care, as most of the
> patches will come from Fedora, I guess we could use the Fedora way.
>

Good question. I think its probably easier to make /lib(64)? equivalent
to /usr/lib(64)?

E.g. use /usr/lib(64)?

and add:

/lib /usr/lib
/lib64 /usr/lib64

.. To file_contexts.subs_dist

2014-01-14 13:34:49

by cpebenito

[permalink] [raw]

Subject: [refpolicy] systemd policy

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.

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.

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

2014-01-14 13:54:57

[permalink] [raw]

Subject: [refpolicy] systemd policy

On Tue, 2014-01-14 at 08:34 -0500, Christopher J. PeBenito wrote:
> There's also questions about the socket activation and how that fits in.

I think Fedoras' policy also does not deal elegantly with socket
activation. I would like to see a separate interface with all the
relevant socket activation rules in there.

2014-01-14 14:41:49

[permalink] [raw]

Subject: [refpolicy] systemd policy

Le Tue, 14 Jan 2014 08:34:49 -0500,
"Christopher J. PeBenito" <[email protected]> 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.

2014-01-14 14:49:23

[permalink] [raw]

Subject: [refpolicy] systemd policy

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

On 01/13/2014 04:07 PM, Dominick Grift wrote:
> On Mon, 2014-01-13 at 21:22 +0100, Dominick Grift wrote:
>> On Mon, 2014-01-13 at 15:16 -0500, Daniel J Walsh wrote:
>>
>>>>
>>> Well I would not say we don't care about other init systems, since we
>>> still need to support systemV init scripts. I removed
>>> init_run_daemon(unconfined_t) because it was causing us problems with
>>> "Daemons" attempting to run as unconfined_u:system_r:unconfined_t:s0.
>>> We are attempting to tighten security on confined domains being able to
>>> transition to unconfined domains.
>>
>> I suspect you removed it to get rid of the role transition on init daemon
>> entry files, and i believe my solution deals with that without the need
>> to remove that interface call.
>>
>> http://oss.tresys.com/pipermail/refpolicy/2013-December/006740.html
>>
>> I briefly tested the above patch and it seems to "work"
>>
>>
>
> https://www.youtube.com/watch?v=gqUFSKplehA
>
> Here is a quick demo with some tests to see if above patch works
>
> youtube is also processing a larger video that demonstrates the whole
> process from implementing the change to testing it
>
>
>
Yes I like your solution. Could you make the change in Fedora.

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

iEYEARECAAYFAlLVTnIACgkQrlYvE4MpobNmFgCeMSXg+mlWsbVuQOV7xw7L1BGJ
fx0AoNu8WGvX/eQJTc1XZOChZutpim0u
=Y4bT
-----END PGP SIGNATURE-----

2014-01-14 14:55:39