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.
With these patches we can call semodule -V %{POLICYVER} ... and new
rebuilds of selinux-policy wouldn't be disrupted by userspace
upgrades. The only downside is that we would need to remember to
increment the specfile versions from time to time.
OTOH, maybe the build failure is actually a good thing in that it
serves as a reminder to bump all the hard-coded versions whenever
userspace bumps max policyvers...
