Bug 118604

Summary:	policy-sources should conflict policy, not require it!
Product:	[Fedora] Fedora	Reporter:	Aleksey Nogin <aleksey>
Component:	policy	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	fred.new2911, gczarcinski, pgraner
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-04-22 20:03:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	114961

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.