SELinux Module Packaging in FC5

[Joshua Brindle]

> From: Paul Howarth [mailto:paul at city-fan.org] 
> 
> Joshua Brindle wrote:
> >> From: Paul Howarth [mailto:paul at city-fan.org]
> >>
> >> On Tue, 2006-06-20 at 16:12 -0400, Christopher J. PeBenito wrote:
> >>> 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.
> >>>>>>> If this is going to be common, then semodule_package and 
> >>>>>>> libsemanage need to allow for policy packages that
> >> have no policy module.
> >>> [cut]
> >>>> - 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).
> >>> I was looking at what it would take to support a package 
> without a 
> >>> module.  Without the binary policy, there is one problem of
> >> where the
> >>> module name and version will come from.  We could either
> >> add this to
> >>> the package itself (which would require a policy package format 
> >>> change), or add a section to the package for module name
> >> and version
> >>> (which seems like a hack to me).
> >> What I'm suggesting isn't a policy package with just file 
> contexts, 
> >> it's one with no allow/dontaudit rules in the policy, like this:
> >>
> >> ::::::::::::::
> >> contagged.if
> >> ::::::::::::::
> >> # contagged.if
> >> #
> >> # This module has no interfaces
> >> ::::::::::::::
> >> contagged.fc
> >> ::::::::::::::
> >> /var/cache/contagged(/.*)?
> >> gen_context(system_u:object_r:httpd_cache_t,s0)
> >> ::::::::::::::
> >> contagged.te
> >> ::::::::::::::
> >> # It's currently only necessary to set file contexts for the cache 
> >> directory # in this policy, but doing it in a module is 
> easier from a 
> >> package maintenance # point of view than using semanage 
> and chcon in 
> >> scriptlets
> >>
> >> policy_module(contagged, 0.3)
> >>
> >> ########################################
> >> #
> >> # Declarations
> >> #
> >>
> >> require {
> >>         type httpd_cache_t;
> >> };
> >>
> >>
> >> ########################################
> >> #
> >> # Local policy
> >> #
> >>
> >> # (none needed)
> >>
> >>> More importantly, I believe a package without a module does
> >> not make
> >>> sense because the types and users used in the file 
> contexts should 
> >>> either be declared or required by the module in the package.
> >>> Otherwise the transaction fails late when the file contexts are 
> >>> validated, rather than early during linking.
> >> I agree. It would make sense for compilation/linking of the module 
> >> above to fail if the "require" wasn't present.
> >> Currently that doesn't happen.
> >>
> >> Paul.
> >>
> > 
> > Try putting a line with just ; where the rules would go and see if 
> > that compiles.
> 
> What I'm saying is that the module compiles just fine without 
> the "require" section, and I think it might be better if it 
> didn't (or at least emitted a warning) since the .fc part 
> references httpd_cache_t.
> 
> Paul.
> 

Not necessarilly. For example, a policy that declares 2 roles and does a
role allow between them, while not useful, is valid. No requirements
would be necessary then.