Архитектура Charantej: Лаборатория защищенной контейнерной подготовки и телеметрии системных вызовов

Корпоративная платформа комплексной защиты контейнеров и телеметрии безопасности времени выполнения. Разработанная с точки зрения ведущего архитектора кибербезопасности Cisco, архитектура Charantej изолирует подготовительные среды выполнения, ограничивает поверхность системных вызовов и инструментирует телеметрию ядра в реальном времени с помощью аудита на уровне хоста для защиты современных развертываний Linux-контейнеров.

Проектирование высокого уровня (HLD)

Архитектура Charantej обеспечивает изоляцию, контейнеризацию с минимальными привилегиями и внешний мониторинг для гарантии устойчивости границ безопасности к векторам компрометации ядра хоста.

flowchart TD
    subgraph HostOS ["Host OS (Secured Linux Node)"]
        subgraph Docker ["Docker Container Runtime"]
            App["Audited App Namespace"]
        end
        
        subgraph Auditor ["Host Auditor (Falco Engine)"]
            eBPF["eBPF Probes"]
        end
        
        Kernel["Host Linux Kernel"]
    end
    
    SIEM["SIEM / Log Repository"]

    App -->|System Calls| Kernel
    Kernel -->|Trace Events| eBPF
    eBPF --> Auditor
    Auditor -->|Telemetry Logs| SIEM
    
    style HostOS fill:#1e1e1e,stroke:#333,stroke-width:2px
    style Docker fill:#2a2a2a,stroke:#007bff,stroke-width:2px
    style Auditor fill:#2a2a2a,stroke:#dc3545,stroke-width:2px
    style Kernel fill:#333,stroke:#ffc107,stroke-width:2px
    style SIEM fill:#1e1e1e,stroke:#28a745,stroke-width:2px,stroke-dasharray: 5 5

Границы доверия

1. Песочница среды выполнения контейнера: Пространство имен контейнера работает строго от имени непривилегированного пользователя, лишаясь всех стандартных возможностей Linux (CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW и т.д.) для блокировки низкоуровневых манипуляций с сетью на уровне системы.
2. Белый список системных вызовов: Пользовательский профиль Secure Computing Mode (seccomp) действует как шлюз между контейнеризированными процессами и ядром хоста, предотвращая доступ к опасным системным вызовам сокетов или изменения пространства имен.
3. Внешняя инструментация: Аудит событий выполняется вне полосы на уровне хоста с помощью зондов трассировки eBPF. Это гарантирует, что даже если среда выполнения контейнера скомпрометирована, журналы телеметрии не могут быть изменены или отключены из контекста контейнера.

Проектирование низкого уровня (LLD)

Проектирование низкого уровня определяет операционную логику проверки системных вызовов, пути фильтрации и конечные точки мониторинга в границах ядра.

flowchart TD
    subgraph ContainerSpace ["Container Namespace (User Space)"]
        App["Audited Process"]
    end

    subgraph SeccompBoundary ["Seccomp Syscall Filter Boundary"]
        Syscall["Syscall Invocation"]
        Filter{"Syscall in Whitelist?"}
        Block["SCMP_ACT_ERRNO (Block & Fail)"]
        Allow["Allow & Pass"]
    end

    subgraph KernelSpace ["Linux Host Kernel Space"]
        Handler["System Call Handler"]
        Subsystem["Target Subsystem (e.g., Network/Memory)"]
    end

    subgraph TelemetryLayer ["Host Auditing Layer"]
        eBPF["eBPF Probe Instrumentation"]
        Falco{"Event Matches Rule?"}
        Alert["Log syslog / SIEM Alarm"]
    end

    App -->|1. Invokes Syscall| Syscall
    Syscall --> Filter
    Filter -->|No: e.g., setsockopt/socket| Block
    Filter -->|Yes: e.g., read/write| Allow
    Allow --> Handler
    Handler --> Subsystem
    Handler -->|2. Traces Execution| eBPF
    eBPF --> Falco
    Falco -->|Yes| Alert

Архитектура Charantej состоит из трех взаимосвязанных слоев конфигурации для обеспечения границ безопасности.

1. Защищенная подготовка контейнера (среда выполнения контейнера)

Конфигурация оркестрации реализует следующие средства контроля безопасности непосредственно через флаги среды выполнения:

• --cap-drop=ALL: Удаляет все стандартные возможности ядра Linux, предотвращая получение контейнером низкоуровневых административных привилегий.
• --security-opt no-new-privileges:true: Предотвращает получение дочерними процессами больше привилегий, чем у родительского процесса, через двоичные файлы setuid или setgid.
• --security-opt seccomp=seccomp-profile.json: Реализует фильтрацию системных вызовов по белому списку.

2. Шлюз белого списка системных вызовов (seccomp-profile.json)

По умолчанию фильтр seccomp в Docker разрешает широкий список системных вызовов. Архитектура Charantej ограничивает его абсолютным минимумом, необходимым для базового выполнения процессов:

• Действие по умолчанию (SCMP_ACT_ERRNO): Блокирует все системные вызовы, если они явно не разрешены в профиле.
• Разрешенные системные вызовы: Разрешает только фундаментальные примитивы работы (такие как read, write, exit, exit_group, futex, nanosleep, mmap, munmap, mprotect и close).
• Заблокированные векторы: Явно блокирует манипуляции с socket, изменения сети через setsockopt, присоединение к пространствам имен (setns) и установку возможностей (), нейтрализуя попытки неавторизованного локального повышения привилегий (LPE).

3. Трассировка телеметрии eBPF (концептуальная)

Правила трассировки на уровне хоста концептуально контролируют границы процессов и системных вызовов:

• Det_Anomalous_Networking: Аудирует параметры сокетов и немедленно выдает CRITICAL ALERT, если какой-либо контейнеризированный процесс пытается изменить протоколы верхнего уровня или свойства ULP (имя опции TCP_ULP).
• Container_Privilege_Escalation_Attempt: Сигнализирует о неавторизованных попытках присоединения к пространствам имен (setns) или изменения наборов возможностей (capset).

Демонстрация живого эксплойта (CVE-2026-46300 "Fragnesia")

Этот репозиторий включает симуляцию живого эксплойта для CVE-2026-46300 для практической демонстрации эффективности архитектуры Charantej. Эксплойт пытается использовать два вектора:

1. Побег из пространства имен: Попытка захвата пространства имен монтирования хоста с помощью setns().
2. Повреждение ULP ядра: Попытка неавторизованного манипулирования памятью ULP через setsockopt(TCP_ULP).

Запуск теста эксплойта

Предоставляется вспомогательный скрипт для автоматической сборки эксплойта и его запуска против незащищенного контейнера (представляющего уязвимую систему) и контейнера, защищенного Charantej.

1. Убедитесь, что Docker запущен.
2. Выполните тестовый скрипт:
   root@kitploit:~

   bash run_exploit.sh
   

Ожидаемые результаты

1. Незащищенная среда (этап эксплойта)

Эксплойт успешно выполнит оба вызова setns() и setsockopt(), сообщив о статусе "VULNERABLE".

sequenceDiagram
    participant App as Unprivileged App (Fragnesia Payload)
    participant Cap as Capability Check (Kernel)
    participant NS as /proc/self/ns/mnt (Host Namespace)
    participant Sys as Syscall Interface
    participant ULP as Kernel ULP Memory

    Note over App,ULP: STAGE 1: Namespace Hijacking
    App->>Cap: 1. setns(FD, 0)
    Cap-->>App: Allowed (No cap_drop)
    App->>NS: Hijack Host Namespace
    NS-->>App: SUCCESS: Container Isolation Bypassed

    Note over App,ULP: STAGE 2: ULP Memory Corruption (CVE-2026-46300)
    App->>Sys: 2. socket(AF_INET, SOCK_STREAM, 0)
    Sys-->>App: FD allocated
    
    App->>ULP: 3. setsockopt(FD, IPPROTO_TCP, TCP_ULP, "tls")
    Note right of ULP: Attempts unauthorized memory modification
    ULP-->>App: SUCCESS: Malicious payload injected
    Note over App,ULP: IMPACT: Host Kernel Memory Compromised!

2. Защищенная среда Charantej (этап смягчения)

Эксплойт перехвачен. setns() блокируется снятием возможностей (EPERM), а socket() / setsockopt() явно нейтрализуются границей фильтра системных вызовов Seccomp (или снятием возможностей в зависимости от профиля выполнения), сообщая о статусе "BLOCKED". Это подтверждает, что даже если полезная нагрузка Fragnesia выполняется, архитектура Charantej надежно изолирует хост от эксплойта.

sequenceDiagram
    participant App as Unprivileged App (Fragnesia Payload)
    participant Cap as Capability Drop (ALL)
    participant NS as /proc/self/ns/mnt (Host Namespace)
    participant Sec as Seccomp Filter Boundary
    participant ULP as Kernel ULP Memory

    Note over App,ULP: STAGE 1: Namespace Hijacking Attempt
    App->>Cap: 1. setns(FD, 0)
    Cap-->>App: BLOCKED (EPERM - Operation not permitted)
    Note left of Cap: Defense Triggered: Namespace escape neutralized
    
    Cap-xNS: Cannot reach Host Namespace

    Note over App,ULP: STAGE 2: ULP Memory Corruption Attempt
    App->>Sec: 2. socket() / setsockopt(TCP_ULP)
    Sec-->>App: BLOCKED (EPERM - Operation not permitted)
    Note left of Sec: Defense Triggered: Socket operations neutralized
    
    Sec-xULP: Cannot reach Kernel ULP Context
    
    Note over App,ULP: IMPACT: Exploit completely contained. Host is Safe!