From: dominick.grift@gmail.com (Dominick Grift)
Date: Sat, 02 Aug 2014 10:23:33 +0200
Subject: [refpolicy] RFC: Supporting tmpfiles policy-wise
In-Reply-To: <20140729161202.GA12297@siphos.be>
References: <20140729161202.GA12297@siphos.be>
Message-ID: <1406967813.1826.6.camel@x220.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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)