Google's Kernel Runtime Security Instrumentation (KRSI) Is Something To Look Forward To In 2020
Back in September was an initial "request for comments" by Google on some kernel work they are doing with Kernel Runtime Security Instrumentation (KRSI) for providing eBPF-powered security helpers, ultimately for creating dynamic MAC and audit policies. Just before Christmas the first official version of this new eBPF-based instrumentation was sent out and is being prepared for deployment within Google.
The patch series proposing KRSI to bpf-next explains the background and design of the Kernel Runtime Security Instrumentation:
The patch series also goes on to describe how KRSI differs from Landlock LSM and other security modules currently available within the kernel tree.
Google engineers have used KRSI to also construct some sample users for logging of execution events, detecting the deletion of running executables, writes to process memory, and related work. Google has begun deploying this instrumentation to their Linux workstations and is hoping to get this code mainlined soon. Depending upon how quickly it matures, we could potentially see the Kernel Runtime Security Instrumentation arrive with the Linux 5.6 cycle.
The patch series proposing KRSI to bpf-next explains the background and design of the Kernel Runtime Security Instrumentation:
Google does rich analysis of runtime security data collected from internal Linux deployments (corporate devices and servers) to detect and thwart threats in real-time. Currently, this is done in custom kernel modules but we would like to replace this with something that's upstream and useful to others.
The current kernel infrastructure for providing telemetry (Audit, Perf etc.) is disjoint from access enforcement (i.e. LSMs). Augmenting the information provided by audit requires kernel changes to audit, its policy language and user-space components. Furthermore, building a MAC policy based on the newly added telemetry data requires changes to various LSMs and their respective policy languages.
This patchset proposes a new stackable and privileged LSM which allows the LSM hooks to be implemented using eBPF. This facilitates a unified and dynamic (not requiring re-compilation of the kernel) audit and MAC policy.
The patch series also goes on to describe how KRSI differs from Landlock LSM and other security modules currently available within the kernel tree.
Google engineers have used KRSI to also construct some sample users for logging of execution events, detecting the deletion of running executables, writes to process memory, and related work. Google has begun deploying this instrumentation to their Linux workstations and is hoping to get this code mainlined soon. Depending upon how quickly it matures, we could potentially see the Kernel Runtime Security Instrumentation arrive with the Linux 5.6 cycle.
17 Comments