[RFC] /var versus /srv

[Karl MacMillan]

On Thu, 2007-09-27 at 14:28 -0400, Richard Hally wrote:
> Jesse Keating wrote:
> > On Wed, 26 Sep 2007 20:52:45 -0600
> > Richi Plana <myfedora at richip.dhs.org> wrote:
> > 
> >> Technically, those SELinux policies should come or be set by the
> >> installation package. Would you happen to know what Fedora's stand on
> >> that is?
> > 
> > Not possible until SELinux upstream allows files to be written out with
> > an unknown context or unabled context and switch to the new policy when
> > it gets applied.
> > 
> > Or something like that.  Long long history and anger around this issue.
> > 
> 
> Huh?
> 
> http://fedoraproject.org/wiki/PackagingDrafts/SELinux
> http://fedoraproject.org/wiki/PackagingDrafts/SELinux/PolicyModules
> 

The basic problem is that packages that contain SELinux policy often
contain new types and the package installs files that should get those
new types. So you end up with a chicken and egg problem - the package
has the policy which needs to be installed before the package.

There are a few solutions:

1) Separate packages for policy and apps - the app depends on the policy
package. The problem is that the order packages are installed during a
transaction can't be guaranteed, so this doesn't always solve the
problem. It also means more packages.

2) Have rpm treat the policy specially - the rpm maintainers don't want
to do this (I can understand).

3) Have rpm set contexts that aren't yet valid. This option was explored
and there was even a kernel patch that would allow this. The fear is
that it would allow a malicious package to create files with _any_
context that is not yet valid. It makes it difficult or impossible to
constrain rpm. You could go back after the policy is installed and check
for contexts that are still invalid and fix those. No decision was
reached about how to handle the hole and nothing happened. The SELinux
upstream developers (well, at least me) are willing to reconsider this
proposal.

4) Allow the files to be laid down with whatever types the current
policy gives them and relabel based on the new policy in post. This
means touching every file twice (worst case) and also has some security
concerns.

4 is a reasonable option except for performance concerns and that is
what those packaging guidelines suggest (last I checked).

Karl