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