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