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.
>
> > 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...
>
--
Ondrej Mosnacek <omosnace at redhat dot com>
Software Engineer, Security Technologies
Red Hat, Inc.
