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. -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
