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.
On 7/29/2014 12:12 PM, Sven Vermeulen wrote:
> 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
[...]
> 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
I agree that it should be its own module.
> - 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
[...]
> 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.
If it's SELinux-aware, why doesn't it setfscreatecon() instead of
relabeling?
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Wed, Jul 30, 2014 at 02:42:05PM -0400, Christopher J. PeBenito wrote:
> On 7/29/2014 12:12 PM, Sven Vermeulen wrote:
> > 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
> [...]
> > 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
>
> I agree that it should be its own module.
>
> > - 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
> [...]
> > 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.
>
> If it's SELinux-aware, why doesn't it setfscreatecon() instead of
> relabeling?
tmpfiles does not always create the dir, if it already exists it just
relabels. It can sometimes also be used to clear out a dir and such
things.
-- Jason
On Tue, 2014-07-29 at 18:12 +0200, Sven Vermeulen wrote:
> 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.
>
you can look at how i implemented tmpfiles policy
(github.com/doverride/e145), although that policy also leaves much to be
desired it might be inspiring.
(for one, i would like to implemented a tmpfiles_etc_object() for
confined administration)
As said tmpfiles does not always have to create the object in order to
restore it.
One can define something like -z /bla and it will do and restore the
context of /bla
tmpfiles can be used to maintain object all over the place.
one (creative) example is how dwalsh uses it in his selinux-policy to
restore the context of certain objects in /sys on boot time.
In theory it, i suppose, should be able to maintain pretty much all on
auth/security with maybe some exceptions (i suppose user content is a
likely exceptio to the rule)
I implemented a glorious hack to allow certain file object type to be an
exception to tmpfiles manageable/relabelable content
That allows one to easily exclude a type (opt out of tmpfiles)