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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> wrote:

On 2/6/20 9:19 AM, Ondrej Mosnacek wrote:
On Thu, Feb 6, 2020 at 2:44 PM Stephen Smalley <sds@xxxxxxxxxxxxx> 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.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux