Re: [RFC PATCH 2/2] semodule: support changing policyvers via command line

[Stephen Smalley <sds@tycho.nsa.gov>]

On 2/6/20 1:47 PM, Stephen Smalley wrote:
> On 2/6/20 10:35 AM, Stephen Smalley wrote:
>> On 2/6/20 10:28 AM, Ondrej Mosnacek wrote:
>>> On Thu, Feb 6, 2020 at 3:52 PM Stephen Smalley <sds@tycho.nsa.gov> 
>>> wrote:
>>>>
>>>> On 2/6/20 9:19 AM, Ondrej Mosnacek wrote:
>>>>> On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@tycho.nsa.gov> 
>>>>> wrote:
>>>> Seems like you could just have selinux-policy depend on the version of
>>>> libsepol used to build it.
>>>>
>>>> The problem with both your current approach and your proposed one is
>>>> that it means that if a user or package does a semodule -B (or any 
>>>> other
>>>> semodule/semanage command) on their system, that will generate the
>>>> latest policy.N version supported by their libsepol, and libselinux 
>>>> will
>>>> give precedence to that policy at load time.  So if they then later
>>>> update their selinux-policy package, and it only installs a prebuilt
>>>> policy.(N-1), that won't actually get loaded - libselinux
>>>> selinux_mkload_policy() will keep using the policy.N file (which may be
>>>> older).  Unless I'm missing something.
>>>
>>> Hm, yes, you're right... It seems we have no other choice than to
>>> better handle the dependency between selinux-policy and libsepol.
>>> Please disregard this patch series.
>>
>> Historically, I think we got to this point because originally 
>> selinux-policy would run semodule from %post to generate the policy.N 
>> file at install time, thereby always generating the latest version 
>> supported, and then later switched to pre-building policy.N at package 
>> build time and just dropping it in place at install time to avoid the 
>> runtime and memory overhead.  Particularly because it could otherwise 
>> fail at install time on low-memory systems/VMs.
>>
>> As a separate matter, one could possibly argue that libselinux 
>> selinux_mkload_policy() should give preference to the newest file 
>> (i.e. timestamp-based) rather than the latest policy version.  But 
>> even if we were to make that change going forward, it won't help with 
>> existing distro releases.
> 
> I guess that doesn't help either since the timestamp of the policy.N 
> file generated at package build may still be older than that of any 
> locally generated one, even if the package was installed later.

Looks like selinux-policy.spec has preInstall and postInstall macros 
that are triggering a rebuild of policy (semodule -B) if there are any 
/etc/selinux/targeted/policy/policy.* files that differ from the 
packaged one.  So if the user did a semodule -B or any other 
semodule/semanage command previously that generated a newer policy 
version (or the same version but with different contents) then the 
package install is going to run semodule -B and re-generate it anyway.
I guess it isn't broken then.