File contexts again

[Stephen Smalley]

On Thu, 2006-06-01 at 12:08 +0100, Paul Howarth wrote:
> Stephen Smalley wrote:
> > On Wed, 2006-05-31 at 13:58 -0400, Christopher Ashworth wrote:
> >> On Wed, 2006-05-31 at 13:05 -0400, Stephen Smalley wrote:
> >>> On Wed, 2006-05-31 at 12:54 -0400, Christopher Ashworth wrote:
> >>>> On Wed, 2006-05-31 at 17:50 +0100, Paul Howarth wrote:
> >>>>> Hmm, that doesn't explain why file contexts that aren't regexes do 
> >>>>> actually work. So if I have:
> >>>>>
> >>>>> /home/pgsql/pgstartup\.log      -- 
> >>>>> gen_context(system_u:object_r:postgresql_log_t,s0)
> >>>>>
> >>>>> this actually works as expected, even though the /home/[^/]*/.+
> >>>>> homedir context also matches.
> >>>> Ah, true.  I forgot you had said that this behavior was occurring.  It
> >>>> seems I have misremembered what is happening.  Let me look again to
> >>>> confirm what's going on.
> >>> libselinux gives precedence to fully specified pathnames (no regex
> >>> characters).  Doesn't matter where they fall within the config files.
> >> Ah, right; thanks.  (As specified in libselinux/src/matchpathcon.c)
> >>
> >> So what I said before was true, modulo the fact that when the actual
> >> call to matchpathcon is made, one final sort is performed, to give fully
> >> specified pathnames precedence.
> 
> Is there some reason why this final sort is only done for 
> fully-specified pathnames and doesn't use the same comparison function 
> as lower down in the hierarchy?

This is essentially just a legacy issue - the libselinux ordering of the
multiple separate file_contexts sources and sorting of fully specified
entries all predates the libsemanage ordering and sorting, and not
everyone is necessarily using managed policy via libsemanage.

We also have a strange side effect of the current handling of local file
contexts vs. homedirs, as the pre-merging of local file contexts by
libsemanage alters its effective priority relative to homedirs compared
to the legacy logic in libselinux.  

> >> Seems like the end-to-end process is a bit confusing, what with several
> >> layers of sorting going on, but I can't immediately suggest an
> >> improvement.  I guess it's just a matter of documenting the life of file
> >> contexts as clearly as possible.
> > 
> > Ultimately, we'd like to migrate all integration and ordering of the
> > various file contexts sources into libsemanage and eliminate the need
> > for it in libselinux.  Mostly a legacy issue.
> 
> So that would mean that the file contexts would be sorted in the order 
> previously discussed, no matter where their origin was (base policy, 
> semodule, semanage, homedir etc.)? That would be much clearer :)
> 
> Whilst we're stuck with the existing ordering, is there a way to disable 
> generation of the homedir contexts, so that someone could then add the 
> contexts from file_contexts.homedirs to policy using semanage instead? 

I don't think so, at present.  homedir_template is generated from the
base file_contexts, so one would have to strip the template expressions
from the base policy to cause it to be empty, which would presumably
render genhomedircon a no-op.  Doesn't appear to be a way to suppress
genhomedircon invocation at present by libsemanage, or even a config
option for it. 

> This shouldn't be too onerous for most users of targeted policy with 
> only user_u and root to worry about. The result would be a set of 
> contexts that obeyed the expected ordering rules, wouldn't it?

-- 
Stephen Smalley
National Security Agency