[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: selinux prelink avc's (broken paths in policy?)

Christopher Ashworth wrote:
On Wed, 2006-05-24 at 16:38 +0100, Paul Howarth wrote:
So if "semanage fcontext -l" doesn't produce an ordered listing, is there any way from userland to get one, one that encompasses both the base policy and any added modules or context objects added using semanage?

I don't know the definitive answer on a userland tool.  semanage
fcontext -l appears to just be calling libsemanage, which is in turn
using Ivan's database functions to list the objects (in this case, the
fcontext objects).  I'll try to track down what happens between the
file_contexts file and the listing.

I take it as read that semanage-added objects and the file contexts from policy module packages (.pp files) are seen as "later" in the list than the base file_contexts file, but which has precedence for semanage/semodule? Last one in? Does it make a difference whether "semodule -i" or "semodule -u" are used?

When semanage_direct_commit is invoked in libsemanage, the following
things happen:

 - any modules are linked to the base module
 - the file contexts in the linked base are sorted
 - the file contexts are split into the file_contexts file and the other
template files, and written to disk (well, to the sandbox, which is then
loaded in a separate step)
 - any semanage-added "database" objects are then merged

Thus, all fcontexts in the linked base (i.e. any fcontext associated
with a module) are sorted together.  The semanage-added objects are done
last, outside of the module sorting, and so would have precedence, as I
understand it.  The database code is a little opaque and not well
documented, so there may be some subtlety I'm missing as to how the
database objects are merged, but this is my current understanding.

I think the best policy, for the avoidance of confusion for people writing policy modules or calling semanage in rpm post-install scripts, is to encourage them to use strings that will sort as "more specific", i.e. avoid metacharacters if possible, and if not, use as long a stem as possible. This probably means having two separate entries for things that will go under /lib or /lib64, rather than the current idiom of /lib(64)?, which has a metacharacter very early in the string.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]