[refpolicy] RFC: Supporting tmpfiles policy-wise

[cpebenito@tresys.com (Christopher J. PeBenito)]

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
www.tresys.com | oss.tresys.com