Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
jailer — Jailer ist ein auf eBPF basierendes Prozess-Jailing-System, das eine verbindliche Zugriffskontrolle (MAC) für Linux bereitstellt. Es verfolgt Prozesse mithilfe von BPF-task_storage-Maps und setzt rollenbasierte Richtlinien für Dateizugriff, Netzwerkoperationen und Prozessausführung durch. | Kitploit
Tools/GitHubGitHub/gen0sec/jailer
DefensivwerkzeugeContainer-SicherheitNetzwerksicherheitCloud-Sicherheit
GitHubgen0sec/jailer

jailer

Repository anzeigenWebseite
582vor 18 TagenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →

Über

Jailer ist ein auf eBPF basierendes Prozess-Jailing-System, das eine verbindliche Zugriffskontrolle (MAC) für Linux bereitstellt. Es verfolgt Prozesse mithilfe von BPF-task_storage-Maps und setzt rollenbasierte Richtlinien für Dateizugriff, Netzwerkoperationen und Prozessausführung durch.

Teilen

Jailer - eBPF-basierte obligatorische Zugriffskontrolle (MAC)

Warnung: Dieses Projekt befindet sich in intensiver Entwicklung und ist NICHT bereit für den Produktionseinsatz. APIs, Richtlinienformate und Verhalten können sich ohne Vorankündigung ändern. Nur zu Test- und Experimentierzwecken verwenden.

Danksagungen

Hinweis: Dies ist eine unabhängige Implementierung und nicht dasselbe Projekt wie die Lösung von Meta. Obwohl BpfJailer funktional ähnlich und vom ursprünglichen Konzept und Design von Liam Wisehart, Justin Nga, Carl El Khoury, Mansee Chadha bei Meta inspiriert ist, handelt es sich um eine separate, unabhängig entwickelte Codebasis. Wir danken für die Vision und die grundlegenden Konzepte, die diese Arbeit inspiriert haben.

Community

Join us on Discord Substack

Jailer ist ein eBPF-basiertes Prozess-Isolierungssystem, das eine obligatorische Zugriffskontrolle (MAC) für Linux bereitstellt. Es verfolgt Prozesse mithilfe von BPF-task_storage-Maps und setzt rollenbasierte Richtlinien für Dateizugriff, Netzwerkoperationen und Prozessausführung durch.

Funktionen (Aktuelle Version)

Nginx-Demo

Nginx-Demo

Komplexe Demo

asciicast

Kernel-Anforderungen

Mindest-Kernel-Version

  • Linux 5.11+ (für BPF_MAP_TYPE_TASK_STORAGE-Unterstützung)
  • Empfohlen: Linux 6.1+ (bessere BTF-Unterstützung)

Erforderliche Kernel-Konfiguration

root@kitploit:~
# Aktuelle Kernel-Konfiguration prüfen
zcat /proc/config.gz 2>/dev/null || cat /boot/config-$(uname -r)

Erforderliche Optionen:

root@kitploit:~
CONFIG_BPF=y
CONFIG_BPF_SYSCALL=y
CONFIG_BPF_LSM=y
CONFIG_DEBUG_INFO_BTF=y

BPF LSM aktivieren

BPF LSM muss in den Kernel-Boot-Parametern aktiviert sein:

root@kitploit:~
# Prüfen, ob BPF LSM aktiv ist
cat /sys/kernel/security/lsm
# Sollte "bpf" in der Liste enthalten

# Falls nicht, zu den Kernel-Boot-Parametern hinzufügen:
# /etc/default/grub bearbeiten und zu GRUB_CMDLINE_LINUX hinzufügen:
#   lsm=lockdown,capability,landlock,yama,apparmor,bpf

# Dann grub aktualisieren und neu starten:
sudo update-grub
sudo reboot

Für Ubuntu/Debian-Systeme kann auch Folgendes verwendet werden:

root@kitploit:~
# Ein Skript erstellen, um BPF LSM zu aktivieren
cat > /tmp/enable_bpf_lsm.sh << 'EOF'
#!/bin/bash
GRUB_FILE="/etc/default/grub"
if grep -q "lsm=" "$GRUB_FILE"; then
    sudo sed -i 's/lsm=[^""]*/lsm=lockdown,capability,landlock,yama,apparmor,bpf/' "$GRUB_FILE"
else
    sudo sed -i 's/GRUB_CMDLINE_LINUX="\(.*\)"/GRUB_CMDLINE_LINUX="\1 lsm=lockdown,capability,landlock,yama,apparmor,bpf"/' "$GRUB_FILE"
fi
sudo update-grub
echo "BPF LSM aktiviert. Bitte neustarten."
EOF
chmod +x /tmp/enable_bpf_lsm.sh
sudo /tmp/enable_bpf_lsm.sh

Build

Voraussetzungen

root@kitploit:~
# Rust installieren
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

# Build-Abhängigkeiten installieren (Ubuntu/Debian)
sudo apt-get install -y clang llvm libelf-dev linux-headers-$(uname -r)

# BPF-Ziel für Rust installieren
rustup target add bpfel-unknown-none

Alle Komponenten bauen

root@kitploit:~
cd bpfjail

# BPF-Programme bauen
cd bpfjailer-bpf && cargo build --release && cd ..

# Daemon und Client bauen
cargo build --release

Schnellstart

1. Den Daemon starten

root@kitploit:~
# Als root ausführen (lädt config/policy.json, falls vorhanden)
sudo RUST_LOG=info ./target/release/bpfjailer-daemon

Erwartete Ausgabe:

root@kitploit:~
[INFO] BpfJailer daemon starting...
[INFO] Loading BpfJailer eBPF programs with libbpf-rs...
[INFO] ✓ pending_enrollments map available for enrollment
[INFO] ✓ network_rules map available for port/protocol filtering
[INFO] ✓ task_storage map created successfully
[INFO] ✓ Program task_alloc attached
[INFO] ✓ Program file_open attached
[INFO] ✓ Program socket_bind attached
[INFO] ✓ Program socket_connect attached
[INFO] ✓ Program bprm_check_security attached
[INFO] Initialized with default roles: restricted (1), permissive (2)
[INFO] Loaded policy from config/policy.json
[INFO] Loaded 5 roles
[INFO] Enrollment server listening on /run/bpfjailer/enrollment.sock

2. Sicherheitstests ausführen

root@kitploit:~
# Sicherheitslücken-Tests OHNE Jail ausführen (zeigt erfolgreiche Angriffe)
sudo python3 tests/vulnerable_apps/run_tests.py

# Sicherheitslücken-Tests MIT eingeschränkter Rolle ausführen (zeigt blockierte Angriffe)
sudo python3 tests/vulnerable_apps/run_tests.py --role 1

# Bestimmten Test ausführen
sudo python3 tests/vulnerable_apps/run_tests.py --role 1 --test path

# Verfügbare Tests und Rollen auflisten
sudo python3 tests/vulnerable_apps/run_tests.py --list

Beispielausgabe mit eingeschränkter Rolle:

root@kitploit:~
============================================================
TEST: Path Traversal / Arbitrary File Read
============================================================
Attempting to read /etc/passwd via path traversal...
BLOCKED - Permission denied (BpfJailer blocked file access)

============================================================
TEST: Command Injection
============================================================
Attempting command injection...
BLOCKED - Permission denied (BpfJailer blocked exec)

============================================================
TEST: Reverse Shell / Data Exfiltration
============================================================
Test 1: Reverse shell connection to 127.0.0.1:4444
BLOCKED - Permission denied (BpfJailer blocked connect)

Verfügbare Sicherheitstests

3. Manueller Anmeldetest

root@kitploit:~
#!/usr/bin/env python3
import socket
import json
import os

# Verbindung zum Daemon herstellen
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
sock.connect("/run/bpfjailer/enrollment.sock")

# Mit eingeschränkter Rolle anmelden (ID 1)
request = {"Enroll": {"pod_id": 1, "role_id": 1}}
sock.send((json.dumps(request) + "\n").encode())
response = sock.recv(4096).decode()
print(f"Anmeldung: {response}")
sock.close()

# Versuchen, eine Datei zu lesen (sollte blockiert werden)
try:
    open("/etc/passwd").read()
    print("Dateizugriff: ERLAUBT")
except PermissionError:
    print("Dateizugriff: BLOCKIERT")

Richtliniendatei

BpfJailer lädt Rollen aus einer JSON-Richtliniendatei. Der Daemon sucht in dieser Reihenfolge nach der Richtliniendatei:

  1. Umgebungsvariable $BPFJAILER_POLICY
  2. /etc/bpfjailer/policy.json
  3. config/policy.json (relativ zum Arbeitsverzeichnis)

Beispiel-Richtliniendatei

root@kitploit:~
{
  "roles": {
    "restricted": {
      "id": 1,
      "name": "restricted",
      "flags": {
        "allow_file_access": false,
        "allow_network": false,
        "allow_exec": false
      },
      "network_rules": []
    },
    "webserver": {
      "id": 3,
      "name": "webserver",
      "flags": {
        "allow_file_access": true,
        "allow_network": true,
        "allow_exec": false
      },
      "network_rules": [
        {"protocol": "tcp", "port": 80, "allow": true},
        {"protocol": "tcp", "port": 443, "allow": true}
      ]
    }
  },
  "pods": []
}

Richtlinien-Flags

Standardrollen

Netzwerk-Port/Protokoll-Filterung

BpfJailer unterstützt feingranulare Netzwerkkontrolle mit Pro-Port-TCP/UDP-Regeln.

Regelstruktur

root@kitploit:~
network_rules map:
  Schlüssel: { role_id, port, protocol, direction }
  Wert: allowed (1) oder denied (0)
  • protocol: 6 = TCP, 17 = UDP
  • direction: 0 = bind, 1 = connect
  • port: 0 = Wildcard (alle Ports)

Regel-Auswertungsreihenfolge

  1. Auf spezifische Portregel für die Rolle prüfen
  2. Auf Wildcard-Portregel (port=0) für die Rolle prüfen
  3. Auf role_flags zurückfallen (Bit 1 = Netzwerk erlaubt)

Beispiel: Nur HTTP/HTTPS für die eingeschränkte Rolle erlauben

root@kitploit:~
// Im Daemon-Code:
use bpfjailer_daemon::process_tracker::{PROTO_TCP, DIR_CONNECT};

// Nur TCP-Verbindungen zu den Ports 80 und 443 erlauben
process_tracker.add_network_rule(RoleId(1), 80, PROTO_TCP, DIR_CONNECT, true)?;
process_tracker.add_network_rule(RoleId(1), 443, PROTO_TCP, DIR_CONNECT, true)?;

Protokoll-Konstanten

Portbereiche

Portbereiche können in policy.json mit port_start und port_end angegeben werden:

root@kitploit:~
{
  "network_rules": [
    {"protocol": "tcp", "port": 443, "allow": true},
    {"protocol": "tcp", "port_start": 8000, "port_end": 8100, "allow": true}
  ]
}
FeldBeschreibung
portEinzelner Port (z.B. 80)
port_start + port_endPortbereich (z.B. 8000-8100)

Hinweis: Große Bereiche (>1000 Ports) verbrauchen viele BPF-Map-Einträge. Bei Bereichen über 1000 Ports wird eine Warnung protokolliert.

Architektur

root@kitploit:~
┌─────────────────────────────────────────────────────────────┐
│                     User Space                               │
├─────────────────────────────────────────────────────────────┤
│  ┌─────────────┐    ┌──────────────────┐                    │
│  │   Client    │───▶│  bpfjailer-daemon │                    │
│  │  (enroll)   │    │                  │                    │
│  └─────────────┘    │  - PolicyManager │                    │
│                     │  - ProcessTracker│                    │
│                     │  - EnrollmentSvr │                    │
│                     └────────┬─────────┘                    │
│                              │ writes to                    │
│                              ▼                              │
├─────────────────────────────────────────────────────────────┤
│                     BPF Maps                                 │
│  ┌──────────────────┐  ┌─────────────┐  ┌──────────────┐   │
│  │pending_enrollments│  │ role_flags  │  │ task_storage │   │
│  │   (PID → info)   │  │ (role→flags)│  │(task→info)   │   │
│  └──────────────────┘  └─────────────┘  └──────────────┘   │
├─────────────────────────────────────────────────────────────┤
│                     BPF LSM Hooks                            │
│  ┌────────────┐ ┌───────────┐ ┌─────────────┐ ┌──────────┐ │
│  │ task_alloc │ │ file_open │ │socket_bind/ │ │bprm_check│ │
│  │(inheritance│ │(migration │ │  connect    │ │_security │ │
│  │ + init)    │ │ + check)  │ │  (check)    │ │ (check)  │ │
│  └────────────┘ └───────────┘ └─────────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────┘

Anmeldeablauf

  1. Prozess verbindet sich mit /run/bpfjailer/enrollment.sock
  2. Sendet JSON: {"Enroll": {"pod_id": N, "role_id": M}}
  3. Daemon schreibt in pending_enrollments[PID] und role_flags[role_id]
  4. Beim nächsten Syscall (file_open, exec) migriert BPF die Anmeldung zu task_storage
  5. Alle zukünftigen Syscalls prüfen task_storage + role_flags auf Durchsetzung
  6. Kindprozesse erben über den task_alloc-Hook

Installationsmodi

BpfJailer unterstützt zwei Installationsmodi:

1. Daemon-Modus (Standard)

Verwendet einen laufenden Daemon für Anmeldung und Richtlinienverwaltung:

root@kitploit:~
# systemd-Dienst installieren
sudo cp config/bpfjailer-daemon.service /etc/systemd/system/
sudo cp target/release/bpfjailer-daemon /usr/sbin/
sudo mkdir -p /etc/bpfjailer
sudo cp config/policy.json /etc/bpfjailer/

# Aktivieren und starten
sudo systemctl daemon-reload
sudo systemctl enable bpfjailer-daemon
sudo systemctl start bpfjailer-daemon

Funktionen:

  • Socket-basierte Anmelde-API
  • Heißes Richtlinien-Neuladen (Daemon stoppen/starten)
  • Vollständige Protokollierung im Daemon-Prozess

2. Daemonloser Modus (Bootstrap)

Lädt BPF-Programme beim frühen Booten und beendet sich. Die Programme bleiben bis zum Neustart aktiv:

root@kitploit:~
# Bootstrap-Dienst installieren
sudo cp config/bpfjailer-bootstrap.service /etc/systemd/system/
sudo cp target/release/bpfjailer-bootstrap /usr/sbin/
sudo mkdir -p /etc/bpfjailer
sudo cp config/policy.json /etc/bpfjailer/

# Aktivieren (wird beim nächsten Booten ausgeführt)
sudo systemctl daemon-reload
sudo systemctl enable bpfjailer-bootstrap

# Oder jetzt manuell ausführen
sudo bpfjailer-bootstrap

Funktionen:

  • Kein laufender Daemon (reduzierte Angriffsfläche)
  • BPF-Programme in /sys/fs/bpf/bpfjailer/ verankert
  • Kann ohne Neustart nicht gestoppt werden
  • Audit-Ereignisse werden über den Perf-Puffer an systemd-journald gesendet
  • Nur alternative Anmeldemethoden funktionieren (exec/cgroup/xattr)

Verankerte Programme prüfen:

root@kitploit:~
ls -la /sys/fs/bpf/bpfjailer/
ls -la /sys/fs/bpf/bpfjailer/maps/
ls -la /sys/fs/bpf/bpfjailer/progs/

Audit-Ereignisse anzeigen:

root@kitploit:~
# Ereignisse werden in den Perf-Puffer gesendet, von journald aufgenommen
journalctl -f | grep bpfjailer

Modusvergleich

Fehlerbehebung

"task_storage map creation failed"

root@kitploit:~
# Kernel-Version prüfen (benötigt 5.11+)
uname -r

# Prüfen, ob BPF LSM aktiv ist
cat /sys/kernel/security/lsm | grep bpf

# Prüfen, ob BTF verfügbar ist
ls -la /sys/kernel/btf/vmlinux

"Failed to attach program"

root@kitploit:~
# Prüfen, ob BPF-Programme geladen werden können
sudo bpftool prog list

# Berechtigungen prüfen
sudo capsh --print | grep cap_bpf

Berechtigungsverweigerung bei der Anmeldung

root@kitploit:~
# Sicherstellen, dass der Daemon als root läuft
ps aux | grep bpfjailer

# Socket-Berechtigungen prüfen
ls -la /run/bpfjailer/enrollment.sock

Alternative Anmeldemethoden

Neben der Unix-Socket-Anmeldung unterstützt BpfJailer die automatische Anmeldung basierend auf:

Anmeldung per ausführbarer Datei

Alle Prozesse, die eine bestimmte Binärdatei ausführen, automatisch anmelden:

root@kitploit:~
{
  "exec_enrollments": [
    {
      "executable_path": "/usr/bin/nginx",
      "pod_id": 1000,
      "role": "webserver"
    }
  ]
}

Wenn ein Prozess /usr/bin/nginx ausführt, wird er automatisch mit der Rolle webserver angemeldet. Dies wird durch den Inode der ausführbaren Datei abgeglichen, sodass Symlinks und Hardlinks korrekt behandelt werden.

Anmeldung per Cgroup

Alle Prozesse in einer bestimmten Cgroup automatisch anmelden:

root@kitploit:~
{
  "cgroup_enrollments": [
    {
      "cgroup_path": "/sys/fs/cgroup/bpfjailer/sandbox",
      "pod_id": 2000,
      "role": "sandbox"
    }
  ]
}

Cgroup erstellen und Prozesse hineinverschieben:

root@kitploit:~
# Cgroup erstellen
sudo mkdir -p /sys/fs/cgroup/bpfjailer/sandbox

# Prozess in die Cgroup verschieben
echo $$ | sudo tee /sys/fs/cgroup/bpfjailer/sandbox/cgroup.procs

# Der Prozess ist jetzt automatisch mit der Rolle sandbox angemeldet

Anmeldung per Xattr

Erweiterte Attribute auf ausführbaren Dateien für Anmeldeinformationen setzen:

root@kitploit:~
# Anmelde-Xattr setzen
sudo setfattr -n user.bpfjailer.pod_id -v $(printf '\x01\x00\x00\x00\x00\x00\x00\x00') /path/to/binary
sudo setfattr -n user.bpfjailer.role_id -v $(printf '\x03\x00\x00\x00') /path/to/binary

# Xattr prüfen
getfattr -d /path/to/binary

Wie die automatische Anmeldung funktioniert

  1. Zum Ausführungszeitpunkt (bprm_check_security-LSM-Hook):

    • Prüfen, ob der Inode der ausführbaren Datei in der exec_enrollment-Map ist
    • Prüfen, ob die Cgroup-ID des Prozesses in der cgroup_enrollment-Map ist
    • Wenn gefunden, task_storage automatisch mit pod_id und role_id setzen
  2. Die Anmeldung bleibt über Fork/Exec dank des task_alloc-Hooks bestehen

  3. Richtlinienregeln (Netzwerk, Pfad, Ausführung) werden basierend auf role_id angewendet

Lizenz

GPL-2.0 (erforderlich für BPF-Programme)

Tool herunterladen
MerkmalStatusBeschreibung
Prozessverfolgung✅ FunktionsfähigVerfolgt Prozesse mithilfe der task_storage-BPF-Map
Socket-Anmeldung✅ FunktionsfähigProzesse melden sich über die Unix-Socket-API an
Rollenbasierte Richtlinien✅ FunktionsfähigEingeschränkte und freizügige Rollen
Dateizugriffskontrolle✅ FunktionsfähigDatei-Öffnen-Operationen blockieren/erlauben
Jail-Vererbung✅ FunktionsfähigKindprozesse erben das Jail des Elternprozesses
Netzwerkkontrolle✅ FunktionsfähigSocket-Bind/Connect blockieren/erlauben
Port/Protokoll-Filterung✅ FunktionsfähigPro-Port-TCP/UDP-Erlauben/Verbieten-Regeln
Ausführungskontrolle✅ FunktionsfähigProzessausführung blockieren/erlauben
Pfadabgleich✅ FunktionsfähigDentry-Walking mit Cache-Invalidierung
Signierte Binärdateien🚧 AnsatzBinärsignatur-Validierung (nicht implementiert)
Alternative Anmeldung✅ FunktionsfähigAutomatische Anmeldung per ausführbare Datei, Cgroup oder Xattr
Daemonloser Modus✅ FunktionsfähigBootstrap-Binärdatei verankert Programme beim frühen Booten
Audit-Ereignisse✅ FunktionsfähigPerf-Puffer für systemd-journald-Integration
TestSchwachstelleAbgemildert durch
path_traversalBeliebiges Dateilesen via ../restricted, isolated
command_injectionShell-Befehlsausführungrestricted, webserver, isolated
reverse_shellAusgehende Verbindungen zum Angreiferrestricted, isolated
ssrfZugriff auf interne Dienste/Cloud-Metadatenrestricted, isolated
arbitrary_writeSchreiben in sensible Pfaderestricted
crypto_minerHerunterladen + Ausführen + Verbinden zum Poolrestricted, webserver
privilege_escalationshadow lesen, sudoers schreibenrestricted
FlagBeschreibung
allow_file_accessDatei-Öffnen-Operationen erlauben
allow_networkSocket-Bind/Connect erlauben
allow_execProzessausführung erlauben
allow_setuidSetuid-Operationen erlauben
allow_ptracePtrace-Operationen erlauben
Rollen-IDNameDateizugriffNetzwerkAusführung
1restrictedGesperrtGesperrtGesperrt
2permissiveErlaubtErlaubtErlaubt
3webserverErlaubtPorts 80, 443, 8080Gesperrt
4databaseErlaubtPorts 5432, 6379Gesperrt
5isolatedErlaubtGesperrtGesperrt
6web_with_dbErlaubtPorts 80, 443, 5432, 3306, 6379Gesperrt
7workerErlaubtPorts 443, 5432, 6379, 5672Erlaubt
KonstanteWertBeschreibung
PROTO_TCP6TCP-Protokoll
PROTO_UDP17UDP-Protokoll
DIR_BIND0socket bind()
DIR_CONNECT1socket connect()
AspektDaemon-ModusDaemonloser Modus
AngriffsflächeLaufender DaemonKein laufender Prozess
AnmeldungUnix-Socket + AlternativenNur Alternativen
RichtlinienaktualisierungenHeißes NeuladenNeustart erforderlich
Audit-ProtokollierungDaemon liest Ringpufferjournald via Perf-Puffer
Programm-EntfernungDaemon stoppenNur Neustart
Boot-ReihenfolgeNach network.targetVor basic.target