Red Hat Bugzilla – Bug 118604
policy-sources should conflict policy, not require it!
Last modified: 2007-11-30 17:10:38 EST
1) I installed policy-sources (which required installing the policy
package as well).
2) I modified /etc/security/selinux/src/policy/users (to include
myself with appropriate staff roles) and started using the locally
3) After a while, I ran "up2date -u" which picked up that both policy
and policy-sources need to be updated.
4) up2date -u upgraded the policy package.
!!! At this point, the default policy got installed and loaded,
!!! overriding the local changes. All the processes that were running in
!!! context aleksey:staff_r:staff_t became system_u:object_r:unlabeled_t
5) Later in the up2date -u, the policy-source package was upgraded,
the new locally-augmented policy got rebuilt and loaded and things got
back to normal. But the mis-labeled processes stayed mislabeled (which
caused some files to become mislabeled too).
P.S. At a minimum, the policy files in the policy package should be
%config(noreplace). But the best solution would be to _only_ one
package that would include all the source files and would always do
the make-and-install-and-reload on upgrade.
P.P.S Sticking with just one (source-based) policy package would also
make it easier to implement the RFE in bug 118571.
Added config switches policy-1.9-16
The problem is back - policy-1.9.2-1 loads the default policy even if
policy-sources is installed :-(
It should only replace it if the policy.16 file has not been updated.
It is treating it as a config file.
Right, so on lolicy.15 -> policy.16 upgrade everything "blows up".
What I do not understand, is why does policy-sources require policy
_at all_. I am not even sure having a separate policy package is such
a good idea - IMHO would should have _just_ the policy-sources package
(which could then be just called policy) - this way we can eventually
chage things like system-config-users to do the right thing w.r.t.
policy-sources users file.
Yes that is a screw up. The Makefile should be checking the version
of kernel that is running and then run with or without the -c flag.
Policy includes the /etc/security/default_context and a few other
files that are not in policy-sources. Policy-sources requires
additional packages like checkpolicy, make, m4 that are not required
for regular policy. So it was decided that for minimal install we
would have policy and policy-sources.
I think we will put a requirement in system-config-users for the
The problem with the .15->.16 upgrade was that :
- I had a custom policy-sources .15 set up and loaded
- A new policy package got installed (because of this dependency)
- The policy package installed the default .16 (since there was no .16
- The polciy package loaded the default .16 causing a lot of problems...
In short, at the very least, the policy package %post script should
check whether policy-sources is installed and _not_ do anything in
The more I think about the subject of this report as stated in the
Summary, the more I like the idea. At install time have the user
select the canned policy or policy+sources and only install one of them.
Another possibility would be to have policy-sources just install the
source files like kernel-source does. I haven't noticed if there is a
kernel boot parm that allows you to select which policy to load, but
that might be necessary, too.
Not sure what you mean. The latest policy locks together policy and
policy-sources so you will need to upgrade both once both are
installed. Also I have modified the Makefile and spec file to build
all versions of the kernel policy file. This way all kernels will
work with SELinux.
SELinux newbie alert... My thinking was that if we used
policy-sources like we use the kernel-source RPM, there would be no
need for policy-sources to build the policy when it was installed. The
policy-sources package would be optional, just like kernel-source. We
would use policy-sources for building custom policies under different
names, just like we build custom kernels. For example, if the kernel
required a version 16 policy, a custom name could be policy.16.test1.
This means that we would need a method for switching between the
packaged Fedora policy and our custom policies, just like we switch
between kernels using grub/lilo.
It is not that simple. In some ways you analogy is correct, the
difference is that there are two config files included in
policy-sources that allow the user to customize their policy. users
and tunables.te. These files will be edited with tools like
system-config-users and system-config-securitylevel. If a user wants
to install an executable in a different spot he might need to update
the file_contexts files.
Finally when you upgrade the policy-sources file if you have not
modified the users or tunable files, you will end up with the same
policy.* file as provided from the policy rpm. If you have modified
those files the policy-source upgrade will pick up your local
I see. Still, it seems strange that two different packages would
update the same file. I feel like the build should be moved from
policy-sources to policy, but this probably wouldn't improve the
situation or make your life any easier.