package review?

[Paul Howarth]

On Fri, 2006-07-21 at 12:25 -0700, Michael Thomas wrote:
> Paul Howarth wrote:
> > Michael Thomas wrote:
> > 
> >> A few packages (game server daemons) that I maintain in Fedora Extras
> >> would benefit from having a selinux security policy available.  But
> >> since I'm new to writing selinux policies, I was hoping that someone
> >> from f-s-l could take a peek at what I did and let me know if I've done
> >> things correctly and in the 'recommended' way.
> >>
> >> I've already tested the policy on FC5 to make sure that it works and
> >> produces no 'avc denied' messages:
> >>
> >> http://www.kobold.org/~wart/fedora/crossfire-1.9.1-2.src.rpm
> >>
> >> I wasn't sure exactly which networking rules I would need.  Most of the
> >> ones there were generated by policygentool.  I also couldn't figure out
> >> why some of the rules at the end of crossfire.te were necessary.
> > 
> > 
> > I don't see any domain transition to crossfire_t in your policy; how
> > does it get into that domain?
> 
> It should be there in crossfire.if, no?

That's the interface used to transition to crossfire_t from some other
domain. So if you wanted it to run confined when just started by a
regular unconfined user, you'd need:

crossfire_domtrans(unconfined_t)

in a rules (.te) file. Interfaces are used so that rules and types
defined for one domain can be used from another domain, so that
everything relating to each domain can kept together. So if your policy
was to get merged into upstream policy, this domain transition would go
in the unconfined.te module.

However, if you're providing a standalone module, it probably makes
sense to include this in your own crossfire.te file.

You should check that the transition has happened by running ps with the
"-Z" option to show the process context when you're running the
application.

Note that most things running confined under targeted policy are started
from initscripts and there is no transition from unconfined_t needed (or
wanted). That's not the case here though.

> > Did you follow the guide on Packaging/SELinux on the wiki for actually
> > building the module in your package? I've changed what I do for package
> > building since I last updated that page (and I can't update it any more)
> > and you'll find it won't build on rawhide as there is an
> > selinux-policy-devel package you need as a buildreq there.
> 
> Yes, I used policygentool to generate the policy files, then your
> SELinux page to put it in the package.  I'd like to see an official
> packaging policy for selinux modules for Fedora Extras, but I'm not sure
> that there are many FE contributors looking at selinux yet.  It looks
> like the page has also been copied to PackagingDrafts/SELinux, where you
> should be able to modify it.

Yes, Tibbs contacted me privately about that. I've have a go at updating
it, probably next week.

> Some things that would be nice to clarify:
> 
> Should selinux be added as a subpackage or automatically included in the
> base package?

I don't have a strong opinion either way on this. I've tended to stick
to keeping everything together because I find it easier to manage that
way. As long as the SELinux bits don't get in the way of people not
using them, I don't think it's a problem.

> If selinux is added as a subpackage, what should its Requires: look like
> (or should there even be any?)

I think that could depend on the particular relationship between the
policy and the main package. For instance, if in your package you
patched out the need for temp files and you didn't allow it to use them
in the SELinux policy, the policy package would want to conflict with
any version of the main package prior to the addition of the patch. I
favour Conflicts: for these rather than Requires: because I can see
reasons why people would want to install both parts independently of the
other (non-SELinux users would want the main package without the policy,
and people wanting to learn about SELinux might want the policy package
without the main one).

> Is a single targetted policy enough, or is it necessary to build for all
> selinux variants (mls, strict, targeted)?

If the built module is the same for all policies (which it will be if
there's nothing policy-specific in it), you could just build one module
and load it for all policies.

> > An example of the way I'm currently doing SELinux module packaging can
> > be found here:
> > 
> > http://www.city-fan.org/~paul/extras/mod_fcgid/mod_fcgid.spec
> 
> /me runs screaming from the %defines :)

Understandable. I like to maintain one spec per package rather than
separate ones for each branch. If you're happy to maintain separate
specs for each branch, most of the defines can be hard-coded into the
spec.

Paul.