[Rpm-maint] [RFC] Packaging SELinux Policy in RPMs

[James Antill]

On Thu, 2010-04-01 at 16:45 -0400, Steve Lawrence wrote:
> As discussed, we have decided to rewrite SELinux support in RPM to move
> policy into their own 'policy packages', separate from the associated
> application packages. With this change, we need to take another look at
> the different ways policy can be packaged separately, and the pros and
> cons of each approach.

 Sorry, I'd meant to reply to this sooner, but it's been a really crazy
for me since just before you sent this.

> The first approach is similar to what our previous patchset did, where
> all policy types are stored in one 'policy package', though separate
> from the application package. For example, this approach would have
> these two packages: apache.rpm and apache-policy.rpm, with apache
> containing the normal apache application and apache-policy containing
> all types (mls, targeted, etc) for the apache module. This has a couple
> advantages. Firstly, all policy is in a single package, meaning only one
> rpm needs to be distributed to get all policies. Additionally,
> dependencies are fairly straightforward. For example, apache.rpm would
> Require apache-policy.rpm, and during installation, the correct policy
> type would be extracted and installed based on the system policy type.

 Rpm will have to "install" everything, but maybe you then just have a
giatn zip file or something?? But in the same way you can install
selinux-policy-targeted and selinux-policy-mls now, why not install
everything and then just switch between which is used?
 But maybe you mean something different by "install" than I'm thinking.

> However, this method of policy packaging does have some side effects.
> This method means all policy packages will always be installed, even if
> SELinux is not installed. Similarly, all policy types will be on disk
> even though only one type is active.

 Meh, I doubt that's a big deal.

>  This leads to an issue with
> switching policy types. If we wanted to switch from the targeted to mls
> policy type, for example, we would need a tool to extract and install
> the mls policies from the currently installed policy packages.

 This confuses me ... don't you just have to change /etc/selinux/config
and reboot? (or do whatever that does).

>  Also,
> because we would use RPMs PRCO, you couldn't obsolete a single policy
> type. You could only obsolete an entire policy package.

 No, you can. The two "simple" cases are:

1. In blah-policy you have -mls, -targeted and -scarey, and want to just
remove -scarey

	just put out an update for blah-policy with -scarey not in it.

2. In blah-policy you have -mls and -targeted, and for whatever reason
some/all of -mls is obsoleted by foo-policy(-mls)

	New versions of blah-policy and foo-policy obsolete the old versions of
blah-policy ... yum/rpm will then update both at once (installing
foo-policy if not already installed).

>  It also means
> you can't maintain packages for your custom policy separately (e.g.
> foobar-apache-policy.rpm works with type foobar, while RH keeps
> providing targeted, etc.). You'd instead have to override the upstream
> policy packages with your own.

 Right, that's kind of known, and you couldn't do that with the first
proposal.

> Rather than having a single policy package containing all policy types,
> another option could have separate policy packages for all modules of
> all types. For example, we might have apache-policy-targeted.rpm and
> apache-policy-mls.rpm. This solves some of the previously mentioned
> issues (e.g. obsoletes, policy type switching), but determining which
> policy package to install must now be determined by Yum/RPMs dependency
> solver/checker. There are a few ways to accomplish this, but none are
> perfect.

 Yeh, with any big feature additions here you have to be really careful
that yum/etc. can implement them sanely.

> One method that could solve this is conditional requirements. For
> example, something along these lines:
> 
>     Requires: selinux-policy-targeted ? apache-policy-targeted
>     Requires: selinux-policy-mls ? apache-policy-mls

 Pretty sure that's not going to happen, for instance think about:

1. install blah (which has the above).
2. do more depsolving.
3. decide you need to install selinux-policy-targeted.
   <What do you do now>

...even worse is that you need to do this for all installed packages at
time #3.

> A similar option, but perhaps not as difficult, would be to add runtime
> macro expansion in Requires.  For example, you might have something like
> this:
> 
>     Requires: apache-policy-%{SELINUX_TYPE}

 This has the same problem, everytime SELINUX_TYPE changes your
depsolving is now broken.

> Another option might have all apache-policy-* packages Provide
> apache-policy, and apache would only require apache-policy.  However,
> this would require that Yum/RPM  need some logic to pick the correct
> apache-policy-X package. This also has the same need for dummy packages
> and policy switching issues.

 This is much closer to how other things work, and might be doable. I've
had a patchset/proposal for yum to have way of semi-manually working
these kinds of things out ... ie. repometadata saying things like (if
you want blah, then pick Z over other providers). This was done to try
and solve KDE vs. GNOME providers of certain things, but this seems like
a similar problem to me.
 Is it likely that would work for you?

 We might even be able to do conditionals here (like if selinux-targeted
installed, choose X, if selinux-mls installed choose Y). Although that
is harder.


 One similar but different thing is that it _might_ be possible to have
a new:

Require-all: apache-policy

...and yum would then install _all_ packages which provide that. You'd
probably have to live with it only working it at install time (and maybe
package upgrade time, although that's more painful).

> Another drawback with having all policy types in separate packages is
> the loss of the 'default' type.  Previously, you could specify a module
> as a 'default' type and it could be installed into the current policy,
> no matter the type. With the separate packages, this becomes very
> difficult to implement cleanly.

 Surely you just have apache require apache-policy and
apache-policy-default (where the later doesn't provide the generic).
Then you get both, and your selinux magic merged the -default into the
current.