Description of problem: After installing policy/policy-sources 1.9.2-9 and policycorutils 1.9.2-1 I rebooted. The system get could not load (find) the policy and did a kernel panic. Rebooting with enforcing=0 completed the reboot. The first occurance was on a ix86 (smp P-III) system. I teh repeated (as a test) on a x86_64 system with the same policy updates installed and it also could not load/find the policy. Reboot enforcing=0 went OK. I then went back to the first system (runlevel 3 boot) and did: cd /etc/security/selinux/src/policy/ make load ... load worked fine .. system seems to be OK setenforce 1 ... all hell breaks loose ... ... flood of console avc messages ... cannot ctl-alt-delete ... ... hardware reset ...
One other thing -- I did notice that policy-1.9.2-9 had the file "/etc/security/selinux/policy." whereas previous ones were of the form "etc.security/selinux/policy.16". How does the system know (where is it specified) as to what the file name of the policy is?
OK, now I tried something else on one of the systems (the x86_64). Manually, I did rpm -Uvh --oldpackage for the previous versions of policy, policy-sources, and policycoreutils. I noticed that some files (file_contexts) is being installed "rpmnew" I then rebooted enforcing=0 I then ran "make reload" and "make relabel" reboot and try again ... things still not quite right. I then did make -C /etc/security/selinux/src/policy load This updated file_contexts. I then rebooted enforcing=1 Looking the best so far but things still looked screwed up. I decided to install the src.rpm for setools to see if I could see what was wrong on the x86_64 (installed into private/local rpm build tree). When I did rpm -Uvh, I got lots and lots of messages of the form on the users telimal window: /etc/security/selinux/file_contexts: invalid context root:object_r:staff_home_t on line number 1742 /etc/security/selinux/file_contexts: invalid context root:object_r:httpd_staff_content_t on line number 1743 /etc/security/selinux/file_contexts: invalid context root:object_r:staff_gpg_secret_t on line number 1744 /etc/security/selinux/file_contexts: invalid context root:object_r:staff_home_irc_t on line number 1745 /etc/security/selinux/file_contexts: invalid context root:object_r:staff_mozilla_rw_t on line number 1746 /etc/security/selinux/file_contexts: invalid context root:object_r:staff_mozilla_rw_t on line number 1747 /etc/security/selinux/file_contexts: invalid context root:object_r:staff_home_screen_t on line number 1748 /etc/security/selinux/file_contexts: invalid context root:object_r:staff_home_ssh_t on line number 1749 /etc/security/selinux/file_contexts: invalid context root:object_r:staff_home_xauth_t on line number 1750 /etc/security/selinux/file_contexts: invalid context system_u:object_r:default_context_t on line number 1751 /etc/security/selinux/file_contexts: invalid context system_u:object_r:amanda_recover_dir_t on line number 1752 Question: Without completely reinstalling the system again (which I will do if necessary), how do I go about completely getting rid of the current stuff relating to selinux policy and then install stuff and try again? It appears to me that things have gotten "confused" and I need to start over.
I had the same problem which I solved by booting with enforcing=0 and renaming /etc/security/selinux/policy. to /etc/security/selinux/policy.16 Reboot, relabel, reboot (this spiel is getting old fast btw, especially on my PII) and things work ok for now. I guess this was a packaging error?
Yes a package error. The Makefile is trying to read policyver from the kernel. Problem is on the build machine it can not. So instead of getting the correct version number it put in "". Fixed in policy-1.9.2-11 The policy number is generated within checkpolicy and the kernel.
I suggest you take a good look at what is happening when you try to build the policy rpms. Try running the build as a regular (no priv) user ... I did that in a local/private build tree and got lots of errors ... including where the build was trying to access /selinux/policyvers I believe there needs to be some deep thinking as to how the policy rpms are built ... maybe there is no good way to have a run-only policy rpm. Maybe there must only be a policy-sources rpm which then builds and installs the policy on the running system.
> Maybe there must only be a policy-sources rpm which then > builds and installs the policy on the running system. Yes, that's was I was thinking too (see also bug 118604).
tradeoff, tradeoffs ... see discussion on fedora-selinux-list.
*** Bug 120048 has been marked as a duplicate of this bug. ***