bpflock: eBPF driven security for locking and auditing Linux machines

by do son · July 20, 2022

bpflock – Lock Linux machines

bpflock – eBPF driven security for locking and auditing Linux machines.

Note: bpflock is currently in the experimental stage, it may break, options and security semantics may change, and some BPF programs will be updated to use Cilium ebpf library.

bpflock uses eBPF to strengthen Linux security. By restricting access to a various range of Linux features, bpflock is able to reduce the attack surface and block some well-known attack techniques.

Only programs like container managers, systems, and other containers/programs that run in the host pid and network namespaces are allowed access to full Linux features, containers, and applications that run on their own namespace will be restricted. If bpflock bpf programs run under the restricted profile then all programs/containers including privileged ones will have their access denied.

bpflock protects Linux machines by taking advantage of multiple security features including Linux Security Modules + BPF.

Architecture and Security design notes:

bpflock is not a mandatory access control labeling solution, and it does not intend to replace AppArmor, SELinux, and other MAC solutions. bpflock uses a simple declarative security profile.
bpflock offers multiple small bpf programs that can be reused in multiple contexts from Cloud Native deployments to Linux IoT devices.
bpflock is able to restrict the root from accessing certain Linux features, however, it does not protect against the evil root.

Functionality Overview

Security features

bpflock offer multiple security protections that can be classified as:

Memory Protections
Process Protections
- Fileless Memory Execution
- Namespaces protection
Hardware Addition Attacks
- USB Additions Protection
System and Application tracing
- Trace Application Execution
- Trace Privileged System Operations
Filesystem Protections
- Read-only root filesystem protection
- sysfs protection
Network protections
- bpflock may include in the future simple network protection that can be used in single machine workload or Linux-IoT but will not include Cloud-Native protection. Cilium and other kubernetes CNI-related solutions are by far better.

Semantics

bpflock keeps the security semantics simple. It supports three global profiles to broadly cover the security spectrum, and restrict access to specific Linux features.

profile: this is the global profile that can be applied per bpf program, it takes one of the followings:
- allow|none|privileged : they are the same, they define the least secure profile. In this profile, access is logged and allowed for all processes. Useful to log security events.
- baseline : restrictive profile where access is denied for all processes, except privileged applications and containers that run in the host namespaces, or per cgroup allowed profiles in the bpflock_cgroupmap bpf map.
- restricted : heavily restricted profile where access is denied for all processes.
Allowed or blocked operations/commands:

Under the allow|privileged or baseline profiles, a list of allowed or blocked commands can be specified and will be applied.
- --protection-allow : comma-separated list of allowed operations. Valid under baseline profile, this is useful for applications that are too specific and perform privileged operations. It will reduce the use of the allow | privileged profile, so instead of using the privileged profile, we can specify the baseline one and add a set of allowed commands to offer a case-by-case definition for such applications.
- --protection-block : comma-separated list of blocked operations. Valid under allow|privileged and baseline profiles, it allows to restrict access to some features without using the full restricted profile that might break some specific applications. Using baseline or privileged profiles opens the gate to access most Linux features, but with the --protection-block option some of this access can be blocked.