Microsoft announces IPE, a Linux Security Module that adds new code integrity features to the kernel

Microsoft's embracing of Linux continues, and the company's latest project sees it trying to improve the security and integrity of systems. The Windows-maker has launched a Linux Security Module (LSM) called Integrity Policy Enforcement (IPE).

The kernel add-on gives administrators the option of configuring policies that can enforce integrity requirements across an entire system. It is possible to create a list of binaries that are permitted to run, and specify attributes that need to be checked before execution is allowed.

See also:

• Microsoft shows off new Windows 10 Start Menu on Twitter
• Microsoft seeks to elevate Teams above Zoom with commitments to privacy and security
• Microsoft releases PowerToys v0.16.1 with numerous bug fixes and added telemetry

Microsoft has not designed IPE with general use Linux systems in mind. Rather it is intended for use on devices that have a specific purpose, such as embedded systems built, configured and administered by the owner -- Microsoft gives the example of a network firewall device in a data center. The idea is that there should be no unknowns in the system, to help further bolster security.

In IPE documentation, Microsoft says:

Ideally, a system which leverages IPE is not intended for general purpose computing and does not utilize any software or configuration built by a third party. An ideal system to leverage IPE has both mutable and immutable components, however, all binary executable code is immutable.

The company points out that for the best possible security, it is important that the kernel and root filesystem should be verified. Microsoft points out a few limitations of IPE:

IPE cannot verify the integrity of anonymous executable memory, such as the trampolines created by gcc closures and libffi, or JIT'd code. Unfortunately, as this is dynamically generated code, there is no way for IPE to detect that this code has not been tampered with in transition from where it was built, to where it is running. As a result, IPE is incapable of tackling this problem for dynamically generated code.

IPE cannot verify the integrity of interpreted languages' programs when these scripts invoked via <interpreter> <file>. This is because the way interpreters execute these files, the scripts themselves are not evaluated as executable code through one of IPE's hooks. Interpreters can be enlightened to the usage of IPE by trying to mmap a file into executable memory (+X), after opening the file and responding to the error code appropriately. This also applies to included files, or high value files, such as configuration files of critical system components. This specific gap is planned on being addressed within IPE.

You can find out more on the Integrity Policy Enforcement (IPE) page on Github.

Image credit: Imagentle / Shutterstock