Indication from our userspace team that they will not have a valid userspace
tool using this patch before the 2.6.18 patch window.  Just not enough time. 
Jeremy, Paul are we certain that you can make rpm do what is needed?  Steven, is
their _plan_ on how rpm will work good enough to submit upstream?

The latest plan jeremy and I hatched to satisfy his requirement is to build a
new tool to wrap the policy load with a tool to do the equivalent of


if semodule -i mypolicy.pp fails
   restorecon -p mypolicy.pp
endif


Where restorecon -p mypolicy.pp reads the file context defined in the
mypolicy.pp file and relabels the files on disk with the
system defaults. 

(In reply to comment #1)
> Indication from our userspace team that they will not have a valid userspace
> tool using this patch before the 2.6.18 patch window.  Just not enough time. 
> Jeremy, Paul are we certain that you can make rpm do what is needed?  Steven, is
> their _plan_ on how rpm will work good enough to submit upstream?

A plan should be good enough, and it would help to have a timeframe for the
implementation of userspace support.

I'm quite certain that we can do it, just a matter of timing.  As for the
timeframe for doing it, between test1 and test2 (so targeting around 8 July to
definitely have it done)

Originaly from SDS
***************
Karl MacMillan raised the following concern during the selinux list discussion
last month, which I don't recall being resolved:

"Thinking through this more I realized that if we cannot guarantee ordering
within a transaction we cannot commit any policy modules until the end of the
transaction. Otherwise it will not be possible to have _any_ dependencies
between policy modules, which doesn't seem likely based on my recent
investigations into refpolicy dependencies.

If policy modules are only committed at the end of the transaction, verification
of the rpms will require going back through the headers of every rpm in the
transaction.

Dan, Jeremy, Paul, any thoughts about when the policy modules will be committed?"

(In reply to comment #2)
> The latest plan jeremy and I hatched to satisfy his requirement is to build a
> new tool to wrap the policy load with a tool to do the equivalent of
> 
> 
> if semodule -i mypolicy.pp fails
>    restorecon -p mypolicy.pp
> endif
> 
> 
> Where restorecon -p mypolicy.pp reads the file context defined in the
> mypolicy.pp file and relabels the files on disk with the
> system defaults. 

Under this approach, how does restorecon know which files were set down by rpm?
 The file contexts in the .pp file may contain pathname regexes.  How does this
approach deal with interdependent policy modules that need to be committed together?

We need to make sure that we have a good understanding of how these issues are
to be resolved.  I'd hate to upstream the kernel patch (which has no known
planned users other than rpm) only to find that we still can't solve the problem
of rpm handling of policy modules for other reasons (especially since the
solution to those other problems could lead us in a different direction even in
the kernel mechanism).

We need a solution to the policy dependancy problem before this can possibly
work. Since RPM assumes that it can lay down all the files within a transaction
and at the end of the transaction everything will work since there are no
inter-transaction dependancies this sort of situation can happen: (correct me if
I'm wrong)

RPM determines that package 2 (containing policy 2) depends on package 1
(containing policy 1) and puts those 2 packages in the same transaction. Policy
2 also depends on policy 1. Per the RPM guys the post scripts aren't guarenteed
to run in order so is it possible that package 1 and 2 files are put on disk and
package 2 postscript starts first. The semodule -i fails because the types
needed by policy 2 (which are declared in policy 1) aren't yet available.

The install can't be backed out so now the user has to intervene to install policy.

Second scenerio: mutually dependant policies. Same packages as above but policy
1 depends on policy 2 and policy 2 depends on policy 1. Then no matter what
order the postscripts are executed in the semodule -i fails. The policies must
be installed within the same semodule transaction (eg., semodule -i policy1.pp
-i policy2.pp) or they can't be installed. 

How is RPM going to solve these problems?

Any further thoughts on these issues?  If we are going to upstream the kernel
support, we need to do it soon for 2.6.18.

BTW, I noticed that over on rpm-devel list, jbj has several times mentioned
%pretrans and %posttrans as relevant to selinux policy.  I'm not familiar with
them myself, but assuming that they are pre-transaction and post-transaction
scriptlets, it seems like they could help with the policy module dependency issues.

Our current thoughts on this is to have a wrapper on semoudle -i which will be
called in the post install.  If it fails, it will automatcally relabel the
contented of the pp file to the system defaults.  

Is that satisfactory?

No, because it is no different than what you said before (in comment #2), and
doesn't deal with any of the issues that have been noted, e.g.
(1) handling inter-module dependencies requires being able to install multiple
policy modules from multiple packages as a single operation (either at the
beginning or the end of the transaction), and
(2) relabeling the unlabeled files to system defaults upon policy install
failure requires a list of all such files installed from all packages in the
transaction, not just the .pp files, as those don't necessarily enumerate
individual file paths, just pathname regexes.
Possibly %pretrans or %posttrans could be used to deal with (1), although I
don't know how they work.  For (2), we need rpm to maintain state in some manner
and provide that aggregate list of files to restorecon at the end.
We don't seem to be communicating.

No, because it is no different than what you said before (in comment #2), and
doesn't deal with any of the issues that have been noted, e.g.
(1) handling inter-module dependencies requires being able to install multiple
policy modules from multiple packages as a single operation (either at the
beginning or the end of the transaction)
> Circular dependancies between packages will not be supported.  If you have
Module A requiring Module B and Module B requiring A they have to be in the same
rpm.  
2) We will recursively restorecon over the file regex file paths in the PP
file(s) that fail in the current RPM.  Similarly to what we do now on policy update.

Where do the files that get laid down with 'illegal' contexts get those contexts? 

Inside the rpm do you have a list
filename1 - context1
filename2 - context2
filename3 - context3
and someone else you have the regex's from .fc's

or do you ONLY have filenames and regex's?

If files when they are laid down are being labeled by either a match to the
existing policy or the policy in the rpm then what dan is saying is fine.  If
the only way they got labeled 'illegally' when laid down on the fs is because
they matched an in .pp regex then using those same regex's to go back and check
is fine.  But if the files are laid down with a context stored seperately and
specifically for that file, and does not necessarily (even if it should) match a
regex in the .pp then you have to keep a list of all files laid down.

(1) Even without circular dependencies, it isn't clear that rpm will correctly
handle normal dependencies among policy modules presently when multiple packages
are installed in a transaction.  See Joshua's first scenario.  Also, even if rpm
will order things properly for us, this is going to be much slower than just
running semodule once, either at the beginning of the transaction or at the end
of it, on all of the modules at once.  So if rpm does support %pretrans and
%posttrans, why can't we use them?
(2) Applying restorecon to all files in the filesystem that match the pathname
regexes in the .pp file could relabel files that weren't installed by that
package, as the regex could match other files set down by earlier packages or
runtime files.  Runtime files are the larger concern there, although hopefully
they wouldn't overlap like that.  Not clear to me, but makes me nervous.
Why such resistance to any real integration with rpm?   I understand that
backward compatibility is paramount, but it seems that we can preserve
compatibility while still doing the right thing...

IIUC, rpmbuild will store the file and their contexts in the package header
(leveraging the old support introduced back in FC2) for files that match entries
in the per-package .pp file, and then rpm will use those contexts when available
at install time, otherwise falling back to system defaults.  Thus, the unlabeled
situation occurs when one of those header contexts is applied at install time
but the subsequent policy module insertion either fails completely or succeeds
but does not yield a policy that defines all of those contexts.  Inconsistency
between the header and the .pp is possible in the event of a buggy rpmbuild or
malicious package construction.  Further, we actually need a post check of
whether those contexts were all made valid by the policy update, so we need
those contexts to be available for such validation after the semodule -i completes.

We need some kind of executive decision from RH OS developers on this, today, so
we can get this patch into the 2.6.18 merge window, which is about to close.

Jeremy, Paul?

Just some additional information - I created a small tool that shows the
dependencies between policy modules. Using a small, but reasonable base there
are some, but not a lot of dependencies. So, in the normal case it looks like
module dependencies can be largely, but perhaps not completely, eliminated and
the dependencies are straightforward and non-circular. I will be submitting the
tool for upstream this week. I created an attachment with the output (in
graphviz format - http://www.graphviz.org) and the module.conf. Dependencies on
base are not shown (so any module that only depends on base is not shown).

Created attachment 131563 [details]
Module dependency information

Module dependency information (in graphviz format).

Created attachment 131564 [details]
Modules.conf used to generate the dependency information

Does this change the fundamental requirements:
(1) Need a way to run semodule once on all of the policy modules at the end of
the transaction to avoid ordering problems when there are dependencies (even
straightforward ones) and to avoid the policy rebuild/reload overhead on every
package.  Does %posttrans enable us to do this?
(2) Need a way to check the validity of all contexts set from package headers
after installing policy modules and to relabel any files set down in those
contexts if they are not valid.  This requires that rpm provide the list of
contexts and file paths to the helper/wrapper that performs the policy
installation; the .pp files aren't enough.
Note that (2) is particularly relevant to the kernel patch, as it provides the
safety net for the lack of checking provided by the kernel when labelpriv is used.

Since userspace was unable to come to a solution which allowed for inclusion of
SELinux policy in rpms which did not open the flood gates to additional attack
vectors by either buggy or maliciously crafted rpms this issue will not be
resolved in FC6.  I am going to leave this open against devel in case we are
better able to work together on this going forward in FC7.

I'm going to close this bug as there is currently little/no discussion about how
to handle policy inside and rpm going on.  If/when kernel work is needed to
allow such functionality we can re-open or open a new bug.

I'm ready to discuss whenever. I believe that selinux policy distribution needs reliable and sane packaging.