Make SELinux files as separate package

[trunkmaster]

SELinux modules require to have GNUstep libraries (nextspace-gnustep and NEXTSPACE applications (nextspace-applications) already installed. So SELinux files were moved out of Libraries/gnustep into separate directory. It also will be built as separate RPM package satisfing installed packages requirements.

@fsmunoz please check if I've made correct changes.

[fsmunoz]

@trunkmaster to me it looks fine in terms of having it as a separate package, and the copying them from Libraries instead of using the tar.gz in Sources deals with the point I had mentioned before.

Two more general comments:

1. I looked around guidelines for SELinux packaging and couldn't find something that was indisputably to be followed, but I used https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft as a reference; they list three main choices - integrated into main package (which I chose simply because it was simpler), subpackage or separate package. They list some caveats with the separate package approach, but in the end for NextSPACE they might be irrelevant.

2. Strictly speaking there is no dependency: SELinux policies can be installed before the affected applications exist. If you look into the selinux-policies package you will find, for example, a policy for gdomap that comes bundled (and which I reused). Once applications are installed the existing path definitions in the .fc files will determine the type of the file, and this in turn will likely be used to determine further policies. So without the ns-Login.pp once Login is installed it gets a default context, but if it's installed the executable Login will be marked xdm_t since that's what is defined in ns-Login.fc ; in a way it's better to have the policies installed before* or directly in the RPM of the application (and here the fixfiles and restorecon will be used).

The later was why I bundled them all together instead of dividing them into the "right" packages since it would be more work for little benefit. Having them as a separate RPM works perfectly fine for me, and allows for independent releases etc.

[trunkmaster]

@fsmunoz thanks for clear explanations and link.

@trunkmaster to me it looks fine in terms of having it as a separate package, and the copying them from Libraries instead of using the tar.gz in Sources deals with the point I had mentioned before.

Two more general comments:

1. I looked around guidelines for SELinux packaging and couldn't find something that was indisputably to be followed, but I used https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft as a reference; they list three main choices - integrated into main package (which I chose simply because it was simpler), subpackage or separate package. They list some caveats with the separate package approach, but in the end for NextSPACE they might be irrelevant.

I've read first part of a document and came to a conclusion that separate package is good option for now because:

• if user decide to disable SELinux during running nextspace-install.sh - no need to install modules (I need to check script);
• after SELinux adoption and fixed problems we can review this approach and maybe include each module into appropriate package (ns-Login into nextspace-application, others into nextspace-gnustep);
• package updates should be faster without need to reinstall SELinux modules;
• SELinux modules could be updated independently of application packages.

Does it sound reasonable? What do you think?

2. Strictly speaking there is no dependency: SELinux policies can be installed before the affected applications exist. If you look into the selinux-policies package you will find, for example, a policy for gdomap that comes bundled (and which I reused). Once applications are installed the existing path definitions in the *.fc files will determine the type of the file, and this in turn will likely be used to determine further policies. So without the ns-Login.pp once Login is installed it gets a default context, but if it's installed the executable Login will be marked xdm_t since that's what is defined in ns-Login.fc ; in a way it's better to have the policies installed before or directly in the RPM of the application (and here the fixfiles and restorecon will be used).

By saying "installed before" do you mean that it's possible to install separate nextspace-selinux package before nextspace-gnustep? Could you please explain how /sbin/fixfiles -R nextspace-gnustep restore || : works in this case (there's no nextspace-gnustep package installed yet)?

The later was why I bundled them all together instead of dividing them into the "right" packages since it would be more work for little benefit. Having them as a separate RPM works perfectly fine for me, and allows for independent releases etc.

This point is unclear to me. What do you mean by "more work"? From my point of view, separate nextspace-selinux.spec doesn't clutter nextspace-gnustep.spec with extra information and make package maintaining more easy. Do I miss something?

[fsmunoz]

@trunkmaster it sounds reasonable to me, especially since there are several different possibilities going forward, so an independent package is as good as anything else and if it helps keeping things clearer then it's completely fine.

I mentioned "more work" in the same sense that that policy document uses it (editing one file is "easier" than creating a new one when the goal is to add the policies), but I was actually referring to an option of splitting the policies between the different packages: the Login policy in the apps, the gdomap/gdnc/etc in the gnustep-base, etc. This to me would be more work without any actual benefit for anyone at the current stage.

[trunkmaster]

@fsmunoz Excellent! Thank you for help. Merging...