On Thu, 2010-06-24 at 09:29 +0300, Panu Matilainen wrote:
> On Wed, 23 Jun 2010, Steve Lawrence wrote:
> > On Wed, 2010-06-23 at 11:13 +0300, Panu Matilainen wrote:
> >>
> >> Hmm, this sounds somewhat familiar... isn't this basically a case of "if
> >> these packages are present in transaction, order them before me but do not
> >> actually require them"? The kernel/initrd folks have been requesting such
> >> a feature for a long time. If we can do this in a way that serves both,
> >> all the better.
> >>
> >> Not sure if you've decided something concrete on the outcome of the
> >> previous selinux policy packaging discussion (thread starting at
> >> http://lists.rpm.org/pipermail/rpm-maint/2010-April/002698.html) but for
> >> at least some of the variants something like this seems workable:
> >
> > Yes, we've decided we would split all policy into a separate *-policy
> > packages with the main package requiring it. So apache-policy contains
> > all policies (mls, targeted, etc) and apache requires apache-policy.
>
> Oh, the main package *requires* the policy? In that case you dont need any
> extra ordering to get policies installed before the apps they protect, rpm
> guarantees requires to be installed before the requiring package (except
> if there are dependency loops, but there shouldn't be those in this case).
>
> The order-hint thingie was under the assumption the policies are not
> required (to avoid unnecessarily dragging them in on systems where selinux
> isn't enabled). Or was the hard requirement decided just because there is
> no other way to establish the relation in rpm currently?
>
One reason we used the hard requires is because it's already available
in RPM. Though it's nice because users don't have to think about it. If
someone yum installs apache, apache-policy will automatically be
installed. If they are on an selinux enabled machine, they don't have to
manually install the apache-policy package when they install apache.
Similarly, you wouldn't be able to remove apache-policy without removing
apache, which is nice security-wise, since removing policy can be
dangerous.
As for unnecessarily dragging in policy packages on a machine where
SELinux isn't enabled, while the packages will be installed, the selinux
plugin will only actually install policies if SELinux is enabled. So you
would just end up with policy packages installed, but not the actually
policies. I believe we've mentioned this before in a previous email, and
the consensus was that it wasn't a big deal.
> >> Taking again apache and its policy/policies as an example...
> >> If either all the policies are included in a single package, or provide a
> >> common thing regardless of the variant, then the main apache package could
> >> have something like this (ignore the exact spec syntax for now):
> >>
> >> Requires(order): apache-policy
> >>
> >> ...which creates a kind of soft dependency between apache-policy and
> >> apachge, which dependency resolution ignores but ordering takes into
> >> account as if it were a real dependency, ie anything providing
> >> "apache-policy" needs installing before "apache" itself.
> >>
> >> IF this kind of approach works for selinux policies then it's not even
> >> collection specific, it'd be just a common mechanism which collections
> >> use, and kernel/initrd folks would be happy too.
> >
> > It seems like this could work. So if I understand it correctly, a more
> > complicated selinux example with two packages, each with a policy, might
> > look like this?
> >
> > foo-policy:
> > Requires: collection(selinux-policies)
> > Provides: sepolicy
> >
> > bar-policy:
> > Requires: collection(selinux-policies)
> > Provides: sepolicy
>
> Hmm.. are these two providing the same thing on purpose? I don't quite see
> what that would accomplish, except chaos and confusion :)
>
SELinux has some special ordering requirements that can't be met by the
standard provdies/requires, which is the purpose of the "Add common
collection requires" patch, which as I've found out, will probably break
things. For example, say we these foo/bar rpms without the
Requires(order)/Provides sepolicy. Then rpm could order the installation
like so:
1. selinux-policy
2. foo-policy
3. foo
4. bar-policy
5. bar
With this ordering, the SELinux collection plugin will get triggered
after bar-policy is installed (it's the last member of the
selinux-policies collection). This means foo will already be installed
when policy is loaded and any SELinux labels installed by foo-policy
won't get applied to foo.
The idea with the Requires(order): sepolicy is that anything that
Provides: sepolicy would be ordered before anything that
Requires(order): sepolicy. So because foo Requires(order): sepolicy, and
bar-policy provides sepolicy, bar-policy would be installed first. So
the order becomes:
1. selinux-policy
2. foo-policy
3. bar-policy
4. foo
5. bar
And everything works with policy, but doesn't change the ordering for
anything else, at least that's the idea.
> > foo:
> > Requires: foo-policy
> > Requires(order): sepolicy
> >
> > bar:
> > Requires: bar-policy
> > Requires(order): sepolicy
> >
> > selinux-policy:
> > Provides: collection(selinux-policies)
> > %collection selinux-policies -p <plugin:sepolicy.so>
>
> Yeah, that's thereabouts to what I was thinking of (with the exception of
> the "sepolicy" requires/provides which seem redundant and even
> problematic) the necessary clues to order these are already present: the
> -policy packages belong to a collection (thus requiring the collection
> owner), and the main packages require the policies.
>
> The collection-related requires/provides can (and should) be handled
> behind the scenes, so eg
>
> foo-policy:
> Requires: collection(selinux-policies)
>
> is written in the spec as "Collections: selinux-policies" and this creates
> whatever the dependency and other magic is necessary. Ditto for the
> provides from "%collection selinux-policies".
>
> > Which should order the {foo,bar}-policy packages before both foo and bar
> > and should trigger the sepolicy plugin at the right time.
>
> So the theory goes :) I've a feeling real world ordering with multiple
> different collections and other packages requiring those main packages etc
> might have some surprising results. I guess only time and experimenting
> will tell, and it might well be the selinux policies want some special
> grouping.
>
> - Panu -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
