Description of problem: 1. semodule_unpackage cannot extract all policy packages (speculation: This might be related to policyvers) Example event: libsepol.module_package_read_offsets: wrong magic number for module package: expected 0xf97cff8f, got 0x39685a42 semodule_unpackage: Error while reading policy module from lvm.pp 2. semodule_unpackage cannot properly extract file context file from policy package From "man semodule_unpackage": SYNOPSIS semodule_unpackage <module> [<file contexts>] DESCRIPTION semodule_unpackage is the tool used to extract the SELinux policy module and file context file from an SELinux Policy Package. EXAMPLE # Extract the httpd module file from httpd policy package. $ semodule_unpackage httpd.pp httpd.mod httpd.fc The above suggests that semodule_unpackage should be able to extract the file context file from policy packages. I believe that in practice this does not work as advertised. Last time i checked, i ended up with a empty file context file where it should have been populated.
Dominick, Yes. It won't extract it since it can't parse/read it Test A [root@localhost ~]# semodule_unpackage lvm.pp lvm.mod lvm.fc libsepol.module_package_read_offsets: wrong magic number for module package: expected 0xf97cff8f, got 0x39685a42 semodule_unpackage: Error while reading policy module from lvm.pp [root@localhost ~]# bzip2 -d lvm.pp bzip2: Can't guess original name for lvm.pp -- using lvm.pp.out [root@localhost ~]# file lvm.pp.out lvm.pp.out: SE Linux modular policy version 1, 2 sections, mod version 17, MLS, module name lvm\006 Test B [root@localhost ~]# file lvm.pp lvm.pp: bzip2 compressed data, block size = 900k [root@localhost ~]# semodule_unpackage lvm.pp lvm.mod lvm.fc libsepol.module_package_read_offsets: wrong magic number for module package: expected 0xf97cff8f, got 0x39685a42 semodule_unpackage: Error while reading policy module from lvm.pp [root@localhost ~]# bzip2recover lvm.pp bzip2recover 1.0.6: extracts blocks from damaged .bz2 files. bzip2recover: searching for block boundaries ... block 1 runs from 80 to 113593 bzip2recover: splitting into blocks writing block 1 to `rec00001lvm.pp.bz2' ... bzip2recover: finished [root@localhost ~]# ls lvm.pp rec00001lvm.pp.bz2 [root@localhost ~]# file rec00001lvm.pp rec00001lvm.pp: SE Linux modular policy version 1, 2 sections, mod version 17, MLS, module name lvm\006 [root@localhost ~]# bunzip2 rec00001lvm.pp.bz2 [root@localhost ~]# ls lvm.pp rec00001lvm.pp [root@localhost ~]# semodule_unpackage rec00001lvm.pp rec00001lvm.mod rec00001lvm.fc [root@localhost ~]# ll total 464 -rw-r--r--. 1 root root 14210 Feb 24 17:00 lvm.pp -rw-r--r--. 1 root root 7975 Feb 24 17:22 rec00001lvm.fc -rw-r--r--. 1 root root 217931 Feb 24 17:22 rec00001lvm.mod -rw-r--r--. 1 root root 225930 Feb 24 17:21 rec00001lvm.pp [root@localhost ~]# sedismod rec00001lvm.pp Reading policy... libsepol.policydb_index_others: security: 0 users, 2 roles, 178 types, 4 bools libsepol.policydb_index_others: security: 1 sens, 1024 cats libsepol.policydb_index_others: security: 54 classes, 0 rules, 0 cond rules libsepol.policydb_index_others: security: 0 users, 2 roles, 178 types, 4 bools libsepol.policydb_index_others: security: 1 sens, 1024 cats libsepol.policydb_index_others: security: 54 classes, 0 rules, 0 cond rules Binary policy module file loaded. Module name: lvm Module version: 1.14.1 Select a command: 1) display unconditional AVTAB 2) display conditional AVTAB 3) display users 4) display bools 5) display roles 6) display types, attributes, and aliases 7) display role transitions 8) display role allows 9) Display policycon 0) Display initial SIDs a) Display avrule requirements b) Display avrule declarations c) Display policy capabilities l) Link in a module u) Display the unknown handling setting F) Display filename_trans rules f) set output file m) display menu q) quit Command ('m' for menu): 1 unconditional avtab: --- begin avrule block --- ... Could this file mismatch be part of the issue in the spec file during bzip2? 183 cp %{SOURCE30} %{buildroot}%{_sysconfdir}/selinux/%1 \ 184 bzip2 -c %{buildroot}/%{_usr}/share/selinux/%1/base.pp > %{buildroot}/%{_sysconfdir}/selinux/%1/modules/active/base.pp \ 185 rm -f %{buildroot}/%{_usr}/share/selinux/%1/base.pp \ 186 for i in %{buildroot}/%{_usr}/share/selinux/%1/*.pp; do bzip2 -c $i > %{buildroot}/%{_sysconfdir}/selinux/%1/modules/active/modules/`basename $i`; done \ 187 rm -f %{buildroot}/%{_usr}/share/selinux/%1/*pp* \ 188 mkdir -p %{buildroot}%{_usr}/share/selinux/packages \
(In reply to Simon Sekidde from comment #1) > > Could this file mismatch be part of the issue in the spec file during bzip2? > Could be but i doubt it. If i remember correctly this was an issue even before Fedora started to use bzip compressed policy packages
(In reply to Simon Sekidde from comment #1) > [root@localhost ~]# semodule_unpackage rec00001lvm.pp rec00001lvm.mod > rec00001lvm.fc > [root@localhost ~]# ll > total 464 > -rw-r--r--. 1 root root 14210 Feb 24 17:00 lvm.pp > -rw-r--r--. 1 root root 7975 Feb 24 17:22 rec00001lvm.fc > -rw-r--r--. 1 root root 217931 Feb 24 17:22 rec00001lvm.mod > -rw-r--r--. 1 root root 225930 Feb 24 17:21 rec00001lvm.pp I tried this as well and seems that the file context file was extracted properly. So the second potential issue is not an issue after all.
(In reply to Dominick Grift from comment #2) > (In reply to Simon Sekidde from comment #1) > > > > > Could this file mismatch be part of the issue in the spec file during bzip2? > > > > Could be but i doubt it. If i remember correctly this was an issue even > before Fedora started to use bzip compressed policy packages Actually those were probably not the exact same issues. So this may indeed be related to bzip after all. There is a history of "libsepol.module_package_read_offsets" issues though as google will show you but they've different "magic numbers", so those are probably slightly different issues.
(In reply to Dominick Grift from comment #3) > (In reply to Simon Sekidde from comment #1) > > > [root@localhost ~]# semodule_unpackage rec00001lvm.pp rec00001lvm.mod > > rec00001lvm.fc > > [root@localhost ~]# ll > > total 464 > > -rw-r--r--. 1 root root 14210 Feb 24 17:00 lvm.pp > > -rw-r--r--. 1 root root 7975 Feb 24 17:22 rec00001lvm.fc > > -rw-r--r--. 1 root root 217931 Feb 24 17:22 rec00001lvm.mod > > -rw-r--r--. 1 root root 225930 Feb 24 17:21 rec00001lvm.pp > > I tried this as well and seems that the file context file was extracted > properly. So the second potential issue is not an issue after all. I just tried to reproduce the file context file issue, and now i see how i got the idea that this in the past did not work. Its because some how the extracted file context file end up with pages of comments, but at the end of the file the file context specifications are included after all. Here is how to reproduce that: # cat > bla.te <<EOF policy_module(bla, 1.0.0) type bla_t; allow bla_t self:file read; EOF # cat > bla.fc <<EOF /bla(/.*)? gen_context(system_u:object_r:bla_t,s0) EOF make -f /usr/share/selinux/devel/Makefile bla.pp semodule_unpackage bla.pp bla.mod bla.fc less bla.fc (the file context is all the way below, i have no clue what all those comments do in there and i do not believe they belong there)
Before i go to sleep, one last comment: I found this thread. Looks related: http://comments.gmane.org/gmane.comp.security.selinux/11940
ssekidde, and dwalsh were right. The first issue seems indeed related to selinux-policy.spec. I was able to reproduce that: http://youtu.be/EtEXAxUR89o The second issue though, while just cosmetic, could probably improved a little
(In reply to Dominick Grift from comment #7) > ssekidde, and dwalsh were right. > > The first issue seems indeed related to selinux-policy.spec. I was able to > reproduce that: > > http://youtu.be/EtEXAxUR89o > > The second issue though, while just cosmetic, could probably improved a > little Agreed. I wonder if the extra lines in the second issue are "required" policy syntax formatting. $ cat bla.fc | wc -l 1 vs $ cat bla.fc | wc -l 846
No bug in semodule_unpackage here. It works on policy packages as created by semodule_package. The fact that Fedora later introduced support in libsemanage to handle bzip2'd files and upstreamed that support (and did it while just leaving the file names with only the .pp suffix, not adding a .bz2 suffix) is why you have the possibly confusing behavior you see now. I suppose one could teach semodule_unpackage and _package to handle the bzip2 files as well, but they are working correctly as designed. With regard to the .fc file issue, that's just the result of m4 being applied to the concatenation of the support macros (that's why you can use gen_context in your .fc file source) and the source .fc file itself, along with the fact that comments are not discarded by m4 and are passed through to the output. Again, not a bug in semodule_unpackage.
Thanks, not sure how to deal with these issues then. As said removing the calls to bzip2 from selinux-policy.spec solved the immediate issue, and i did not notice much if any difference in file sizes.
Whoops i take that comment about file sizes back
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.