Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 118604 - policy-sources should conflict policy, not require it!
Summary: policy-sources should conflict policy, not require it!
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: policy
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC2Blocker
TreeView+ depends on / blocked
 
Reported: 2004-03-18 05:18 UTC by Aleksey Nogin
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-04-22 20:03:58 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Aleksey Nogin 2004-03-18 05:18:24 UTC 
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
augmented policy.
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.
Comment 1 Daniel Walsh 2004-03-25 05:22:08 UTC 
Added config switches policy-1.9-16
Comment 2 Aleksey Nogin 2004-04-02 06:40:49 UTC 
The problem is back - policy-1.9.2-1 loads the default policy even if
policy-sources is installed :-(
Comment 3 Daniel Walsh 2004-04-02 13:56:24 UTC 
It should only replace it if the policy.16 file has not been updated.
It is treating it as a config file.

Dan
Comment 4 Aleksey Nogin 2004-04-02 21:33:49 UTC 
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.
Comment 5 Daniel Walsh 2004-04-03 04:55:33 UTC 
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
policy-sources file.
Comment 6 Aleksey Nogin 2004-04-05 02:28:33 UTC 
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
previously)
- 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
that case.
Comment 7 Gene Czarcinski 2004-04-05 17:54:16 UTC 
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.
Comment 8 Fred New 2004-04-06 09:58:04 UTC 
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.
Comment 9 Daniel Walsh 2004-04-06 11:00:12 UTC 
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.

Dan
Comment 10 Fred New 2004-04-06 12:08:09 UTC 
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.

Fred
Comment 11 Daniel Walsh 2004-04-06 12:19:18 UTC 
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
modifications.

Dan
Comment 12 Fred New 2004-04-06 14:10:49 UTC 
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.
Note You need to log in before you can comment on or make changes to this bug.