From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Tue, 29 Jul 2014 18:12:02 +0200
Subject: [refpolicy] RFC: Supporting tmpfiles policy-wise
Message-ID: <20140729161202.GA12297@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hi guys,

I'd like to hear from you about the following - given the discussion on this
list earlier, I think the approach below is the best. Putting tmpfiles in
the not-yet-available systemd policy might not be the best approach, as
tmpfiles support will be needed in other init systems as well as upstream
projects start supporting tmpfiles.d/*.conf.



The tmpfiles application, as documented in [1], is used to prepare directory
structures in runtime, volatile locations (such as /var/run, /run and
perhaps even /tmp and /var/tmp).

[1] http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

The need for the tmpfiles application seems to came forward as systemd
service files ("unit files") are not the flexible shell scripts that are
used in init scripts (/etc/rc.d/init.d/* files). Whereas these init scripts
usually did the preparation of runtime directories, the systemd service
scripts do not (well, beyond the RuntimeDirectory= directive, that is).

Instead, services are required to create a tmpfiles configuration file
inside one of the following locations, informing the tmpfiles application to
create directories and files as needed:

(a.) /usr/lib/tmpfiles.d/ (*.conf) for packaged services (default settings)
(b.) /run/tmpfiles.d/ (*.conf) for dynamically generated overrides of (a.)
(c.) /etc/tmpfiles.d/ (*.conf) for local system administration overrides 
     of (a.) and (b.)

These files declare what action to perform on a specific location (such as
create a directory) and which ownership to apply (similar to the install(1)
application it seems).

Both in systemd as well as OpenRC the tmpfiles application is SELinux-aware,
(re)setting the context of the target.

In my humble opinion, this is a full-fledged application with a defined
interface for administrators, and with specific privileges (creating &
deleting resources all around the place). I think the best approach here
would be to create a separate tmpfiles module, which

- defines the (a.) directory as tmpfiles_usr_lib_t
- defines the (b.) directory as tmpfiles_var_run_t
- defines the (c.) directory as tmpfiles_conf_t
- creates a tmpfiles_t domain that has
-- read privileges on tmpfiles_{usr_lib,var_run,conf}_t
-- create+write+delete privileges on pidfiles, device_t,
   device_node, tmp_t and so forth (cfr [1] documentation)
-- capability to set labels on all resources
- introduce the proper interface(s) to allow other domains to interact with
  the defined resource types

We already had a case for this [2], where kmod dynamically generates a
configuration file in (b.). By having the directory as tmpfiles_var_run_t
and grant insmod_t (the domain used by kmod at that time) create_file_perms
permissions and add_entry_dir_perms permissions on tmpfiles_var_run_t, this
can be safely integrated.

[2] http://oss.tresys.com/pipermail/refpolicy/2014-July/007252.html

As tmpfiles is SELinux-aware and performs restorecon (or similar) internally
on the generated resources (at least from looking at the code, that is) we
don't need to include many file transitions, instead make sure that the
domain is capable of setting contexts.