# Armoring Cloud Native Workloads with BPF LSM

Slides link - https://docs.google.com/presentation/d/1lkyyGTeYcq5PskXsKltFZwDkQBIYSAAxUiCaiEIC_Hk/edit?usp=sharing

Transcript:

Hello Everyone :wave:
Thank You for joining me on my session on "Armoring Cloud Native Workloads with BPF LSM". I am Barun Acharya, A software engineering intern at Accuknox.

Let's first talk about the need to Armor up your workloads. With the rise of adoption of modern cloud native infrastructure so has risen the cyber attacks on the same. With the rise in recent vulnerabilities like log4j and pwnkit there's an ever more demanding need to enforce runtime security.

So what existing mitigation mechanisms do we have for enforcing runtime security. We have Linux Security Modules, LSMs like AppArmor, SELinux, Landlock... These are a mature ecosystem of hooks to enforce various security models. LSMs handle TOCTOU problem well. Then we have Seccomp, Secure Computing, which helps in sandboxing by restricting actions available to containers. LSMs and Seccomp are Linux Kernel features but we can mitigate these using Userspace techniques as well like using LD_PRELOAD.
But each of these come with their set of drawbacks, especially in context of cloud native workloads.

// Drawbacks from slides

// PodSecurityContext

Enter BPF LSM;
BPF LSM combines the powers of the LSM Framework which provides with necessary hooks for inline security enforcement with the flexibility and observability powers of eBPF to help secure our modern cloud-native workloads more efficiently.

Let's venture how these powers can be utilised today.

We very recently had a vulnerability known as Pwnkit in which an unpriviledged user could gain root privileges. Mitigations involved removing SUID bit from exploitable binaries or updating the systems with patched packages. But Denis here created a simple BPF LSM program which can hooks on to `bprm_check_security` and blocks execution of any process with argc 0.

Let's look at another project `kimglock`. Lockdown LSM aims to restrict access to a running kernel image. But it is too restrictive and disables some necessary features like BPF. So ironically this project reimplemented a subset of features leveraging BPF LSM. while still preserving the ability to leverage other LSMs for security enforcement in other parts.

eBPF has changed the game for observability and monitoring. With BPF LSM we can hook on to strategically better placed points in kernel and can help us avoid vulnerabilities exploiting Time-of-check and Time-of-Use. This was covered in a better way last year by KP and Leonardo when they introduce BPF LSM to us on this stage.

So to summarise how we can leverage BPF LSM today is
1. Virtual Patching - A quick program to prevent an exploit for a new vulnerability.
2. We can have security mitigations without full blown policy rules.
3. Stacking with existing LSMs to setup a security perimeter tailored for your workload.
4. Gain more observability at points better located than just tracing syscalls since LSM hooks are strategically placed in the kernel.

But is this enough to protect your workloads? Did we address all the pain points we pointed out in the beginning?
The things we saw BPF LSM is capable is just the beginning and proves that it is capable of much more.
But the ecosystem is still nascent and we can build a more holistic tool to enforce runtime security leveraging information from orchestrators, container managers, syscalls and LSM Hooks.

We at KubeArmor want to solve this problem by combining the LSM Superpowers with the metadata for cloudnative workloads simplyfing the security enforcement.

You can track our work at #link

I would like to end this on the note
> BPF-LSM could possibly change the runtime security landscape for application security just the way eBPF changed it for network security.