SUSE adds security automation support for Kernel Live Patches

Share
Share

SUSE has found that security automation is not handling SUSEs kernel livepatches very well.

To understand the underlying problem and ways toward a solution, lets first look at the underlying concepts.

Kernel Livepatching

Kernel livepatching is a technology where functions within a running Linux kernel are patched to fix security issues, without rebooting or even stopping the kernel. This allows uninterrupted use of workloads over long times.

Kernel livepatches from SUSE are delivered as loadable kernel modules that are delivered in RPMs seperately from the kernel RPMs.

These RPMs are named “kgraft-patch-VERSION” on SUSE Linux Enterprise 12 and “kernel-livepatch-VERSION” on SUSE Linux Enterprise 15.

Every kernel livepatch is crafted for one specific running kernel, so every kernel needs its own livepatches.

This is why the kernel version for which the livepatch is usable is encoded in the RPM name.

SUSE provides livepatch RPMs for each kernel it releases, with a maintenance lifetime of the livepatch for one year after release of the respective kernel.

During this year you can run the selected kernel and updates of the livepatch RPM will bring new livepatches and so fixes for the selected kernel.

The kernel livepatches from SUSE contain only security fixes for CVSS v3.1 score 7.0+ issues and critical bugfixes, which is a small subset of the normal bugfixes compared to regular kernel update.

One year after the specific kernel releae SUSE stops to provide kernel livepatches for this kernel and customers needs to switch to a newer kernel version for livepatch support.

Introspection of Kernel Livepatches

SUSE provides commandline tools for introspecting loaded livepatches.

  • kgr in the kgraft RPM for SUSE Linux Enterprise 12

    Here you can use:
    kgr -v patches
    to get the CVEs and bugs fixed by the current loaded livepatch.

  • klp in the kernel-livepatch-tools RPM for SUSE Linux Enterprise 15

    Here you can use:
    klp -v patches
    to get the CVEs and bugs fixed by the current loaded livepatch.

Security automation

Most security automation that detects unfixed security issues usually does either:

  • test for indicators of the unfixed security issue
  • verifies versions of installed software against the security fixed versions

Most of the current day scanners use the second method, detecting package versions on the system and comparing them against the known fixed versions.

Now, in combination with the kernel livepatches packages, this brings a challenge.

  • a specific security issue in kernel-default-VERSION-AFFECTED can either be fixed either by
    • updating to kernel package version kernel-default-VERSION-FIXED and rebooting
    • OR applying a livepatch in package version kernel-livepatch-VERSION-FIXED (no reboot needed)

Currently most security automation has a direct one to one “package needs to be updated to be fixed” relations, e.g. a CVE for one package must be fixed in the same package.

This is also reflected in security automation data, like CVRF, CSAF or OVAL, which makes expressing this challenging.

One exception is the OVAL format, which has an expression language that can express multiple package-fixed package relationships.

Solution

SUSE has adjusted its “vulnerability” style OVAL format to implement logic to handle livepatches:

A CVE in the kernel-default package is considered fixed, either by:

  • an updated kernel-default package
  • a corresponding kernel-livepatch package update

Note that this could not be done with the “patch” OVAL format, as this reflects only the regular updates that we provide.

Technical implementation

In OVAL “vulnerability” format, SUSE usually uses this expression logic for fixed packages:

AND(
        OR(list of affected products with below packageset),
        OR(list of packages with version-release < fixed package version)
)

For the new kernel live patch method it was enhanced, and the “kernel-default < fixed package version” expression is replaced by a bigger OR() expression block in above package list:

AND(
        OR(list of affected products with below packageset),
        OR(
                AND (kernel-default == version1 ,  NONE SATISFY (kernel-livepatch1 >= fixed version1)),
                AND (kernel-default == version2 ,  NONE SATISFY (kernel-livepatch2 >= fixed version2)),
                ... all kernels listed that have livepatches ...
                kernel-default <= version without livepatch,
                ... more normal kernel subpackage relations ...
        )
)
Share
(Visited 1 times, 1 visits today)
Marcus Meissner
817 views