Trust only your code and data: integrity protection on locked-down Linux systems
Enforcing an integrity policy using dm-verity alongside a Linux Security Module (LSM)
Bella Brahm is a Program Manager in Microsoft COSINE who is working to enhance the security of Microsoft's Linux, Windows, and intelligent edge/IoT offerings. Her focus is on code integrity and application control, and she is jazzed to be a part of the company's efforts to make positive contributions to the Linux ecosystem.
Program Manager in Microsoft, working on enhancing the security of Linux OS'.
I work on Code Integrity (CI) systems within both ntos + linux. My current main area of interest is Integrity Policy Enforcement (IPE), an upcoming Linux Security Module (LSM) that compliments the existing LSMs, and allows sys-admins/sys-builders to enforce integrity requirements on user mode from kernel mode.
Code integrity is an essential part of ensuring that modern operating systems provide platform integrity guarantees against the execution of unauthorized code. Enforcing that only known and trusted (i.e. signed) code can execute on a system raises the bar for attackers significantly, as malicious code will not be signed with trusted certificates.
DM-verity-- one of the preexisting options for doing signing verification and enforcement on Linux systems-- provided a valuable foundation which our project has built upon to ensure that binary executable code executed on Linux platforms is unmodified and of known provenance. DM-verity is a kernel feature which provides read-only integrity checking of block devices, the underlying storage layer of the filesystem. These blocks correspond to a hash tree: the leaves of the tree are pages containing hash values, and each higher level in the tree contains hashes of the blocks below it, all the way up to a signed and trusted root hash. When the kernel tries to access a specific block, the hash associated with that block is verified all the way up to the root hash.
Assume the case of a locked-down Linux system, which has a policy that mandates that all code executing on it must be signed with a valid key. Utilizing signed dm-verity volumes is one of the mechanisms to enforce this. The pre-existing dm-verity implementation focused only on those dm-verity volumes that were loaded before boot, with the root hash being trusted by early boot components such as Trusted Boot or U-Boot. This approach did not account for those volumes that were mounted after OS boot-up.
Microsoft addressed this limitation by providing the capability to perform an in-kernel signature validation of the signed dm-verity volumes that were mounted after boot. In this approach, the signer of the root hash is one that is trusted by the read-only built-in keyring of the kernel. The kernel checks that the root hash was signed with an authorized key from this keyring and allows the volume to be mounted only if it passes signature verification.
By using dm-verity with in-kernel signature verification alongside a Linux Security Module (LSM) to consult and enforce the integrity policy, a robust security architecture can be created which prevents untrusted binaries from executing on the system.
- 45 min
- LinuxFest Northwest 2020
- Information Security