Microsoft launches new Linux Security Module (LSM) for embedded devices

By John Onwuegbu Apr 8, 2020

Share Tweet Share Email

Microsoft has launched new Linux security module (LSM) for embedded devices, called Integrity Policy Enforcement (IPE), which aims to resolve the integrity issue in the Linux kernel by bringing enhanced security features.

IPE will enable a configurable policy that enforce integrity requirements in the whole system, thus helping to solve the issue of code integrity; so that executed codes (or files being read) are identical to versions built by trusted sources.

In other words, IPE is helpful in ensuring that only authorized code by the owner of a system is allowed to execute.

Overview of the Integrity Policy Enforcement (IPE)

While there are multiple implementations within Linux kernel that tends to solve integrity verification, such as device-mapper verity, that ensures integrity of a block device, and fs-verity which ensures integrity for the filesystem.

But these different implementations lack a measure of run-time verification for binaries sourced from the locations.

It is this security gap that IPE aims to address, and given that it's separated between the major components of a configurable policy, and the deterministic attributes, which are provided by the LSM (IPE Core) and the kernel to evaluate files against IPE Properties), respectively.

Different Use Cases for IPE

The new module is designed for devices with specific purpose like embedded systems, including network firewall device, whereby all software and configuration in a data center is built and provisioned.

Any such system that leverages IPE isn't intended for general purpose computing, nor does it utilize software or configuration built by a third party. So the ideal system for IPE should have both mutable and immutable components, albeit, all binary executable code is immutable.

The highest level of security for platform firmware is to verify the kernel as it allows the entire system to be integrity verified and also the root filesystem, though the later is optional.

However, IPE can't verify the integrity of anonymous executable memory, like trampolines created by gcc closures, libffi, or JIT'd code, as there is no way to detect that dynamically generated code has not been tampered in transit from built, to the running.