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

James Antill james at fedoraproject.org
Thu Apr 15 00:34:04 UTC 2010


On Wed, 2010-04-14 at 13:30 -0400, Steve Lawrence wrote:
> On Fri, 2010-04-09 at 10:40 -0400, James Antill wrote:
> > On Thu, 2010-04-01 at 16:45 -0400, Steve Lawrence wrote:
> 
> <snip>
> 
> It seems like you are in favor of bundling all policy into a single
> policy package, adding that as a requirement, and always installing it.
> This is certainly the easiest and least intrusive solution, though we're
> still not convinced it is the best long-term solution. That said, we're
> happy to move forward with it if you see it as the best option.

 I say it more like, I think it's the simplest thing to move to from
where we are now and brings with it significant features.

>  Before
> the decision is made though, we want to make sure the consequences are
> clear:
> 
> Installing SELinux Policy and Infrastructure Becomes a Requirement
> 
>   Right now, SELinux policy and the infrastructure (e.g. libsemanage,
>   policycoreutils) does not need to be installed.

 I'm not sure what you mean here, at least in "my world"
selinux-policy-targeted and policycoreutils are in the "core" group and
are thus. required installs.

[...]

 Also with policy in separate packages, it becomes possible to create
new repos. which don't have policy ... if you _really_ need to.

> Obsoleting/Customizing Modules is Difficult
> 
>   You give the example that you can just update the packages and add
>   conflicts with the previous versions. I agree, for RH, this is a
>   simple solution. However, if you aren't RH, this isn't easy. You would
>   need to create your own version of the packages with your changes, and
>   then watch for any changes to those packages from RH. This is alot of
>   work when all you may want to package is an updated type or module.

 Ahh, I see what you mean. This is the "we want custom policy for apps.
someone else ships" problem, again I think a good solution to solve that
would be a great thing but the original solution of "put policy in
package headers" didn't solve that.
 And it's not quite that bad (says the person least affected by it) as
I'd expect that anywhere doing that will not just have their machines
speaking directly to rhn.redhat.com.

> Policy Type Switching is Still A Problem 
> 
>   When we install policy packages, we would check to see if the modules
>   from that package should actually be installed. For example, if only
>   targeted policy is installed, we can't install the mls apache module
>   (even though apache-policy.rpm is installed). However, if we want to
>   switch to an mls policy after apache-policy.rpm has already been
>   installed, we need to detect that and install the mls apache
>   module. This would likely need to be performed by a separate tool.
>
>   Unless you are saying we should install all policy types all the time.
>   In this case, all you need to do to switch types is edit
>   /etc/selinux/config. However, actually installing all policy types
>   (not just the rpms) all the time is going to increase the rpm transaction
>   time, since there would be a separate semodule call per type, which is
>   very slow.

 I'm not sure our terminology is matching up, what do you mean by
"install" here.
 I'd assume that all the policy in the rpm hits disk in a way that
SELinux policy tools can see it ... but only the current policy type
would be "built" and loaded into the kernel etc.
 So I'd assume we'd incur more I/O (at least for everyone who doesn't
already install mls policy :) ... but all the extra bits of work would
only be done when needed.



More information about the Rpm-maint mailing list