Due to the growing threat posed by file-less malware attacks where malware code is executed from anonymous executable memory pages that aren’t backed by data on the file-system, the “NAX” Linux security module has been seeing work recently for helping to protect against such scenarios.
https://lkml.org/lkml/2021/8/19/971
Typically, the malware first needs to intercept the execution flow (e.g.,
by the means of ROP-based exploit). Then it needs to download the main
part (in the form of normal executable or library) from its server,
because it is hard to implement the entire exploit in ROP-based form.
There are a number of security mechanisms that can ensure the integrity
of the file-system, but we need to ensure the integrity of the code in
memory too, to be sure, that only authorized code is running in the
system.The proposed LSM is preventing the creation of anonymous executable pages
for the processes. The LSM intercepts mmap() and mprotect() system calls
and handles it similarly to SELinux handlers.The module allows to block the violating system call or to kill the
violating process, depending on the settings, along with rate-limited
logging.[JIT]
Because of blocked anonymous code execution, JIT-compiled code, some
interpreters (which are using JIT) and libffi-based projects can be
broken.[Similar implementations]
Although SELinux could be used to enable similar functionality, this LSM
is simpler. It could be used in set-ups, where SELinux would be overkill.There is also SARA LSM module, which solves similar task, but it is more
complex.[Cooperation with other security mechanisms]
NAX LSM is more useful in conjunction with IMA. IMA would be responsible
for integrity checking of file-based executables and libraries, and
NAX LSM would be responsible for preventing of anonymous code execution.Alternatively, NAX LSM can be used with read-only root file system,
protected by dm-verity/fs-verity.
@madaidan comments? Perhaps we can convince them to create exceptions for JIT packages