# Armoring Cloud Native Workloads with BPF LSM

## Bio*
Barun is a pre final year computer science undergraduate student at the Jaypee Institute of Information Technology, Noida in India and currently works as a Software Engineer Intern at Accuknox. Barun is usually hacking on low level stuff and fiddling around developer toolings.

## Abstract Title*

> If your talk is selected, the Abstract Title you choose will be the title shown in the conference schedule, often what attendees use as a starting point to determine if they will be interested in the talk. Choose your title carefully - make sure that it accurately describes what your talk will cover.

Armoring Cloud Native Workloads with BPF LSM

## Abstract*

> Provide an abstract that briefly summarizes your proposal. Provide as much information as possible about what the content will include. Do not be vague.
> This is the description that will be posted on the website schedule if your talk is selected, so be sure to spell check, use complete sentences (and not just bullet points), and write in the third person (use your name instead of “I”).
> Remember that this description is what will make an attendee decide whether your session would be a good fit for them. Be sure to provide enough information to help attendees make the right choice. Be clear and concise.
> The presentation selection process is very competitive, with many proposals rejected. A well-written abstract will greatly increase the possibility of the proposal being accepted.

Cloud Native Workloads are not protected by default as the various tools for security into place provides perimeter security at the host, or the network and not necessarily the workload itself. BPF LSM provides with security hooks necessary to set up least permissive perimeter for various workloads. KubeArmor is a cloud-native runtime security enforcement system that leverages various LSMs to secure the workloads.

There's a need for a declarative policy management system for Mandatory Access Control in modern workloads where underlying infrastructure is abstracted away.

This talk will be about how BPF LSM provides fine grained control over security hooks and how KubeArmor leverages these LSM superpowers to abstract away the complexities, how BPF LSM compares with other LSMs to protect modern workloads and what design considerations/challenges for integrating BPF LSM in KubeArmor.

## Audience*

> Describe who the audience is and what you expect them to gain from your presentation.

1. Developers - Insights about how we can have fine grained control over Linux Security Hooks using BPF LSM
2. DevSecOps - The need to not just monitor but enforce runtime security early in the lifecycle of the project
3. Security Admins - Configurable policy settings leveraging BPF LSM

## Benefits for the Ecosystem*

> Tell us how the content of your presentation will help better the ecosystem. (We realize that this can be a difficult question to answer, but as with the abstract, the relevance of your presentation is just as important as the content).

Containers and Orchestrators have abstracted away the process to develop and ship applications. But security still seems to be heavily reliant on the underlying infrastructure used by cloud providers or various teams.

This talk highlights the need to abstract away runtime security enforcement and how BPF LSM plays an important role in dealing with the abstraction while leveraging eBPF at it's core. How BPF Helper programs can be extended if necessary to handle Mandatory Access Control.
How this will be complementary to PodSecurityContext which leverages mechanisms such as seccomp, SELinux, and AppArmor.

BPF-LSM could possibly change the runtime security landscape for application security just the way eBPF changed it for network security.

# Talk Contents

1. Containers are not contained/ Need for runtime security
2. LSMs help in containment
3. PodSecurityContext
// Dig about hybrid... node support
4. LSMs are complex, not cloud native
5. ~~Enter KubeArmor with declarative security enforcement~~
6. Trouble integrating with existing LSMs
7. AppArmor ~~is opiniated, needed some hacky workarounds here and there~~
8. SELinux treats everything inside the container as a single entity
9. Enter BPF LSM
- Works across distributions ( newer ones... )
- Stackable
- Flexible

~~10. Tuning BPF LSM to setup enforcement system
- Hooks Used
- Design considerations, maps, buffers...~~
11. Establish audit
12. Provides more information to gain more visibility
13. Usecase
- process bases network firewall
- virtual patching
16. ...Not mature enough ecosystem
17. Limitations

// Example https://github.com/evdenis/lsm_bpf_check_argc0
// More examples...
-

LSMs have complicated constructs
Hard with complex rules
Not adapted for modern dynamic environment (k8s/containers)

https://github.com/linux-lock/bpflock
Stacks with Landlock LSM and

# Talk 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 controls as well like using LD_PRELOAD.
But each of these come with their set of drawbacks, especially in context of cloud native workloads.

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.