Hide Forgot
Created attachment 509954 [details] alter selinux-policy.spec to include the 2 patches applied to the source code at various stages during building. Description of problem: During compilation/build of (patched/custom) the targeted selinux policy using rpmbuild I get the following error: /usr/bin/semodule_expand tmp/test.lnk tmp/policy.bin libsepol.sepol_module_package_read: invalid module in module package (at section 0) /usr/bin/semodule_expand: Error in reading package from tmp/test.lnk make: *** [validate] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.3z0Tfc (%install) This error doesn't really tell me anything! The test.lnk file was successfully build after linking all compiled modules (the .pp files), so there is nothing wrong, I think, with the file format, unless semodule_link built an invalid test.lnk file. Version-Release number of selected component (if applicable): The latest policycoreutils as distributed in FC15. The targeted policy was patched up to exclude quite a few modules. I am attaching the 3 patches I used to aid you with reproducing the error. How reproducible: Always. Steps to Reproduce (this assumes that the latest corepolicytools are used): 1. download and install the latest selinux-policy source rpm 2. apply the first patch (selinux-policy-spec.patch) against selinux-policy.spec to activate the 2 subsequent patches applied to the policy source 3. copy the other two patches (policy-3.9.16-1z.patch & policy-3.9.16-2z.patch) to the SOURCES directory 4. cd rpmbuild/SPECS and execute "rpmbuild -bb selinux-policy.spec" Actual results: /usr/bin/semodule_expand tmp/test.lnk tmp/policy.bin libsepol.sepol_module_package_read: invalid module in module package (at section 0) /usr/bin/semodule_expand: Error in reading package from tmp/test.lnk make: *** [validate] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.3z0Tfc (%install) Expected results: Either successful linking of all the modules, or, at least more meaningful error message to be displayed aiding me with finding what the real problem is. Additional info: As mentioned above, I am attaching 3 patches: 1. selinux-policy-spec.patch - alter selinux-policy.spec to include the 2 patches applied to the source code at various stages during building. 2. policy-3.9.16-1z.patch - this patch is applied to the various source files (mostly) removing unused port definitions and corenet_* macro statements. 3. policy-3.9.16-2z.patch - this patch is applied *only* to the modules-targeted.conf file as I was building the targeted policy - the rest have been deactivated - and deactivates quite a few modules from the policy. It does nothing else.
Created attachment 509955 [details] this patch is applied to the various source files (mostly) removing unused port definitions and corenet_* macro statements.
Created attachment 509956 [details] applied *only* to the modules-targeted.conf file deactivating a number of modules
Any movement on this? I tried various "tweaks", but, sadly, with the same effect - even though *all* .pp modules are built and the linking is done, the semodule_expand fails miserably with the same error!
Did this work on previous versions?
No idea is the short answer. I've upgraded all my systems in line with the FC15 distro, so don't know how this will behave with older versions as this is the first time I am trying these rather "radical" cutbacks to the policy. I take it you can reproduce this error (so that I know it is not something "unique" on my system)?
No I have not tried. I would recommend that you remove the modules using semodule -d MODULE and then restorecon, rather then what you are doing. Or you could install selinux-policy-minimum and then slowly enable modules that you want. Not sure why you are removing the port labels, in some ways this might be making your system less stable.
(In reply to comment #6) > No I have not tried. I would recommend that you remove the modules using > semodule -d MODULE and then restorecon, rather then what you are doing. Unfortunately, I can't do that. The (custom) targeted policy forms part of a software image, which is built on a similar principle as Live images are - they have read-only root union-ed with RAM partition. In other words, changes to the root are "permitted" but they only last until reboot, so everything in that root is in effect "crystallised". > Or you > could install selinux-policy-minimum and then slowly enable modules that you > want. I can't do that either for the above reason. > > Not sure why you are removing the port labels, in some ways this might be > making your system less stable. "Less stable" or "less secure"? If it is the latter, I am aware of that - the above exercise, which triggered the problem was "phase 1". "Phase 2" was to "replace" the port_t definition completely by introducing a foreign attribute (in a similar way as you do with "etc_t" in the new policy in FC15) - that way all ports, which are not defined (or have the "default" definition in corenetwork.te.in) will be secured and only those needed (i.e. defined explicitly by other modules in the same policy) will be used. In any case, I think either something is wrong with semodule_expand for giving me this obscure error message, or, semodule_link hasn't done its job properly while linking all those modules (.pp files), or both.
(In reply to comment #4) > Did this work on previous versions? No! I had finally had the chance (and time!) to test just that today. The following distros were tested: 1. Stock FC15 with the latest updates installed 2. LiveCD FC15 with selinux-related updates installed 3. Stock FC14 with the latest updates installed 4. LiveCD FC14 with selinux-related updates installed With all of the above I am getting the same error, so it seems to me that this bug is persistent across all supported distros! FC13 cannot work (I did try that as well!) simply because some of the modules start with numbers and that error in checkpolicy was fixed in FC14 after it was released.
Since this version of Fedora is no longer supported I am closing this bugs. If you are still seeing this bug in a current version of fedora, please reopen the bugzilla with the appropriate version number.