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

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

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:
>>>> On 2/6/20 8:12 AM, Ondrej Mosnacek wrote:
>>>>> When using semodule for building a distribution policy package (as
>>>>> Fedora does), the environment might not have selinuxfs available and
>>>>> provide no way to modify semanage.conf. When we want to build a policy
>>>>> with version X (because our kernel doesn't support X+1 and above yet),
>>>>> but our libsepol already has support for X+1, then we currently have no
>>>>> way to do so.
>>>>
>>>> Not fundamentally opposed, but unclear on the motivation.  The current
>>>> approach is to generate the highest policy version supported by our
>>>> libsepol at build time, then libselinux selinux_mkload_policy() uses
>>>> libsepol functions (sepol_policydb_set_vers(),
>>>> sepol_policydb_to_image()) to automatically downgrade the policy in
>>>> memory to whatever version is supported by the kernel before writing it
>>>> to the kernel.  This works as long as one uses the same or newer
>>>> libsepol at load time as at build time and as long as policydb_write()
>>>> supports writing older policy versions (generally discarding newer
>>>> features).
>>>
>>> The problem is that:
>>> 1. selinux-policy expects that the generated /etc/selinux/.../policy.X
>>> file will be generated with a specific (hard-coded) value X, so if the
>>> userspace is updated in buildroot, the selinux-policy build fails.
>>> 2. If we fix the above by expecting any value X and ship that, then
>>> the build passes in such case, but if a user updates selinux-policy
>>> without updating userspace and reboots, the system will not boot. So
>>> even if we stop incrementing the expected policy version manually, we
>>> would still need to manually increment the minimum required userspace
>>> version each time the policy is rebuilt with userspace that has
>>> incremented its max policyvers.
>>
>> 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.