SELinux Module Packaging in FC5

Paul Howarth paul at city-fan.org
Sun May 21 12:26:10 UTC 2006


On Fri, 2006-05-19 at 08:03 -0400, Stephen Smalley wrote:
> On Thu, 2006-05-18 at 13:39 +0100, Paul Howarth wrote:
> > Paul Howarth wrote:
> > > Stephen Smalley wrote:
> > >> On Tue, 2006-05-16 at 17:33 +0100, Paul Howarth wrote:
> > >>> It contains a policy module, but the module only includes file contexts.
> > >>
> > >> Clarification:  it is a policy package (.pp), but the policy package
> > >> only includes file contexts.  The module itself is just the .mod file
> > >> created by checkmodule; it never includes file contexts.
> > > 
> > > Ah, right, thanks for the clarification.
> > > 
> > >> If this is going to be common, then semodule_package and libsemanage
> > >> need to allow for policy packages that have no policy module.
> > 
> > Is the absence of a policy module the actual cause of this error? If so, 
> > would having a "dummy" policy module that was effectively a no-op (e.g. 
> > by including an allow rule that was already in the base policy) be a 
> > usable workaround?
> 
> No, per Chad (via private email), the problem you encountered was
> actually caused by an unintended side effect of the helpful
> policy_module() macro in refpolicy.  Since that macro expands to include
> require statements for all kernel classes and permissions (so that the
> policy writer doesn't have to manually specify them for each kernel
> class and permission he uses), it unfortunately can pick up requires for
> new classes and permissions in the refpolicy on the build system that
> are not yet defined in the base policy on the target system (in your
> case, due to not having fully updated the target system).  There are
> some changes in progress that should help with that problem.

A possible workaround for that might be for a package to conflict with
selinux-policy versions older than the one it was built against. Is
there a convenient way of finding the selinux-policy version short of
doing an rpm query?

> > Should this be bugzilla-ed?
> 
> I suppose there are two separate issues here:
> - Avoiding unnecessary dependencies in policy modules on the build
> system's refpolicy (of which this is only one instance). There is
> already more general effort in progress to introduce real interfaces
> into the language and module format so that modules can be truly linked
> against the interfaces of the base policy on the target system.
> - Cleanly supporting policy packages that do not include a binary policy
> module in the tools (e.g. semodule_package) and libraries (e.g.
> libsemanage, libsepol), so that they can be used to ship just file
> contexts or other components.  I don't know of any work in progress yet
> on that issue, so it may make sense to bugzilla it, although it is
> really an upstream issue, and there isn't presently an upstream bugzilla
> for selinux (just the mailing list).

OK I'll bugzilla it, but which component should I use?

Paul.




More information about the fedora-selinux-list mailing list