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@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.
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.
