[RFC] /var versus /srv

Panu Matilainen pmatilai at laiskiainen.org
Fri Sep 28 06:11:07 UTC 2007

On Thu, 27 Sep 2007, Karl MacMillan wrote:

> On Thu, 2007-09-27 at 16:18 -0400, Jesse Keating wrote:
>> On Thu, 27 Sep 2007 15:53:38 -0400
>> Karl MacMillan <kmacmill at redhat.com> wrote:
>>> 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.
>> Wouldn't it be reasonable to lay them down as 'undefined_t' and let the
>> post-rpm transactions relabel them?
> That is possible - though obviously you have to handle things cleanly
> for upgrades to that you don't end up with, say, libc labeled as
> undefined_t. So you would have to:
> 1) check every context as you put a file down
> 2) if it is valid set it
> 3) otherwise, set to undefined_t (and ideally add file to list)
> 4) install policy in post
> 5) relabel (ideally with list kept from before)
> Part of the problem, though, is figuring out what the context for a file
> should be. I believe that you can record contexts from when the rpm was
> built, but how do you handle if the admin has a local labeling rule that
> should take effect?

Rpm has been recording file contexts into headers from build time up to 
now, but nothing has been using it (except perhaps in early "selinux 
bootstrap" days, I don't know). I just killed that code a couple of 
weeks ago from rpm upstream, because it's just completely wrong: the 
selinux policy that happens to be loaded on the build host has *zero* 
relevance to that of the target host - could be local rules, or labeling 
differences between targeted/strict/whatever prepackaged policies or 
even just versions of the same policy.

 	- Panu -

More information about the fedora-devel-list mailing list