Architettura Charantej: Laboratorio di Staging Contenitore Rinforzato e Telemetria delle System Call

Un framework di contenimento dei contenitori di livello enterprise, con difesa in profondità e telemetria di sicurezza runtime. Progettato dal punto di vista di un Lead Cybersecurity Architect Cisco, l'Architettura Charantej isola i runtime di staging, restringe le superfici delle system call e strumenta la telemetria del kernel in tempo reale utilizzando l'auditing a livello host per proteggere le moderne implementazioni di contenitori Linux.

---

Progetto di Alto Livello (HLD)

L'Architettura Charantej impone isolamento, contenimento a privilegio minimo e monitoraggio out-of-band per garantire che i confini di sicurezza rimangano resilienti contro vettori di compromissione del kernel host.

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

Confini di Fiducia

1. Sandbox del Runtime del Contenitore: Il namespace del contenitore funge rigorosamente come utente non privilegiato, rimuovendo tutte le capacità Linux predefinite (CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, ecc.) per bloccare le manipolazioni di rete a livello di sistema grezze.
2. Whitelisting delle System Call: Un profilo personalizzato di Secure Computing Mode (seccomp) funge da gatekeeper tra i processi containerizzati e il kernel host, impedendo l'accesso a pericolose system call di alterazione di socket o namespace.
3. Strumentazione Out-of-Band: L'auditing degli eventi viene eseguito out-of-band a livello host tramite sonde di tracciamento eBPF. Ciò garantisce che, anche se un runtime del contenitore viene compromesso, la registrazione della telemetria non possa essere manomessa o disabilitata dal contesto del contenitore.

---

Progetto di Basso Livello (LLD)

Il Progetto di Basso Livello definisce la logica operativa di validazione delle system call, i percorsi di filtro e gli endpoint di monitoraggio all'interno del confine del kernel.

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

L'Architettura Charantej è composta da tre strati di configurazione interconnessi per imporre i confini di sicurezza.

1. Staging Contenitore Rinforzato (Runtime del Contenitore)

La configurazione dell'orchestrazione implementa i seguenti controlli di sicurezza direttamente tramite flag di runtime:

• --cap-drop=ALL: Elimina ogni capacità predefinita del kernel Linux, impedendo al contenitore di ottenere privilegi amministrativi di basso livello.
• --security-opt no-new-privileges:true: Impedisce ai processi figlio di ottenere più privilegi del loro processo padre tramite binari setuid o setgid.
• --security-opt seccomp=seccomp-profile.json: Implementa il filtraggio delle system call con whitelist.

2. Gatekeeper della Whitelist delle System Call (seccomp-profile.json)

Per impostazione predefinita, il filtro seccomp di Docker consente un elenco ampio di system call. L'Architettura Charantej lo restringe al minimo assoluto richiesto per l'esecuzione di base dei processi:

• Azione Predefinita (SCMP_ACT_ERRNO): Blocca tutte le system call a meno che non siano esplicitamente nella whitelist del profilo.
• System Call Consentite: Permette solo primitive operative fondamentali (come read, write, exit, exit_group, futex, nanosleep, mmap, munmap, mprotect e close).
• Vettori Bloccati: Blocca esplicitamente le manipolazioni di socket, le modifiche di rete con setsockopt, le unioni di namespace (setns) e i set di capacità (capset), neutralizzando i tentativi non autorizzati di escalation dei privilegi locali (LPE).

3. Tracciamento Telemetrico eBPF (Concettuale)

Le regole di tracciamento a livello host monitorano concettualmente i confini di processo e system call:

• Det_Anomalous_Networking: Verifica le opzioni dei socket e segnala un immediato ALLARME CRITICO se un processo containerizzato tenta di modificare protocolli di livello superiore o proprietà ULP (opzione TCP_ULP).
• Container_Privilege_Escalation_Attempt: Avvisa su tentativi non autorizzati di unire namespace (setns) o modificare set di capacità (capset).

---

Dimostrazione Live dell'Exploit (CVE-2026-46300 "Fragnesia")

Questo repository include una simulazione live dell'exploit per CVE-2026-46300 per dimostrare praticamente l'efficacia dell'Architettura Charantej. L'exploit tenta due vettori:

1. Escape del Namespace: Tentativo di dirottare il mount namespace host usando setns().
2. Corruzione ULP del Kernel: Tentativo di manipolazione non autorizzata della memoria ULP tramite setsockopt(TCP_ULP).

Esecuzione del Test dell'Exploit

Viene fornito uno script di supporto per costruire automaticamente l'exploit ed eseguirlo contro un contenitore non mitigato (che rappresenta un sistema vulnerabile) e il contenitore protetto da Charantej.

1. Assicurarsi che Docker sia in esecuzione.
2. Eseguire lo script di test:

   bash run_exploit.sh
   

Risultati Attesi

1. Ambiente Non Mitigato (Fase dell'Exploit)

L'exploit eseguirà con successo sia setns() che setsockopt(), riportando uno stato "VULNERABILE".

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!