Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

FluxContactConfidentialité© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
sandboxed-untrusted-code-execution-runner — Exécute du code Python, JavaScript et Bash non fiable dans une prison renforcée avec des limites de 5 secondes, 128 Mo, 0,5 cœur, de PID et de sortie. | Kitploit
Outils/GitLabGitLab/kavryxdev-group/sandboxed-untrusted-code-execution-runner
Outils DéfensifsSécurité des ConteneursAnalyse Dynamique (Sandboxing)Scripting et AutomatisationAudit de ConfigurationVirtualisation de SécuritéSécurité des APIAnalyse de Journaux

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
GitLabkavryxdev-group/sandboxed-untrusted-code-execution-runner

sandboxed-untrusted-code-execution-runner

Exécute du code Python, JavaScript et Bash non fiable dans une prison renforcée avec des limites de 5 secondes, 128 Mo, 0,5 cœur, de PID et de sortie.

Voir le dépôt
4il y a 1 jourPas encore vérifié
Partager

🛡️ Exécuteur d'exécution de code non fiable en bac à sable

Exécution de code non fiable imposée par le noyau — chaque charge utile est confinée par cgroups v2, namespaces, seccomp-BPF et un rootfs en lecture seule, et chaque exécution est auditée dans PostgreSQL.

Go Linux PostgreSQL Redis Docker Status

python · javascript · bash → bac à sable de 5 secondes, 128 Mo, 0,5 cœur, 32 PID, sortie de 512 Ko


Aperçu

Un service d'exécution renforcé pour la sécurité, destiné au code auquel vous ne faites pas confiance. Les appelants soumettent le code source via une petite API REST ; le démon lance chaque charge utile dans une prison éphémère au niveau du noyau où le noyau Linux lui-même — et non la logique applicative — garantit le confinement :

  • le processus ne peut pas s'échapper du système de fichiers (pivot_root vers un rootfs en lecture seule),
  • il ne peut pas communiquer avec le réseau ni avec l'hôte (namespaces privés + lo désactivé + seccomp qui tue socket),
  • il ne peut pas épuiser la machine (plafonds mémoire/CPU/PID via cgroups v2),
  • il ne peut pas survivre à son budget (chien de garde de 5 s en temps réel), et
  • chaque résultat — y compris les violations — est consigné dans une piste d'audit immuable.

Fonctionnalités clés

  • 🧱 Défense en profondeur — six namespaces Linux (PID · MOUNT · NET · IPC · UTS · USER), une liste blanche seccomp-BPF stricte, des prisons de ressources cgroups v2, et un système de fichiers pivot_root en lecture seule avec un espace de travail tmpfs de 16 Mo.
  • ⚡ Démarrages en moins d'une seconde — un pool préchauffé de 16 emplacements d'exécution avec un délai d'acquisition de 3 secondes évite le coût de démarrage à froid par requête tout en bornant la concurrence.
  • ⏱️ Limites déterministes — délai d'expiration strict de 5 s en temps réel, plafond mémoire de 128 Mo (swap désactivé, OOM kill instantané), 0,5 cœur CPU, immunité aux fork bombs via pids.max = 32, et plafonds de sortie de 512 Ko sur stdout/stderr.
  • 📜 Audit complet des exécutions — code de sortie, temps réel, mémoire de pointe, temps CPU, indicateurs de troncature et événements de sécurité sont écrits de manière asynchrone dans PostgreSQL (execution_runs).
  • 🧪 Suite de tests de niveau attaque — tests d'intégration dédiés pour les fork bombs, l'évasion réseau, l'OOM mémoire, le chien de garde de timeout et la charge de concurrence, exécutables dans un conteneur privilégié contre le noyau réel.

Architecture du système

flowchart LR
    CLI["👤 API Client<br/><i>tenant / CI job</i>"]

    subgraph CP["🔐 Trusted Control Plane — Go daemon"]
        API["Ingestion Daemon<br/><i>net/http :8080</i>"]
        POOL["Warm Runner Pool<br/><i>16 slots · 3 s cap</i>"]
        RUN["Process Runner<br/><i>watchdog + pipes</i>"]
        ISO["Kernel Isolation<br/><i>cgroups v2 · namespaces · seccomp-BPF</i>"]
    end

    subgraph JAIL["⛓️ Ephemeral Kernel Jail — untrusted"]
        INIT["sandbox_init<br/><i>exec trampoline</i>"]
        GUEST["💀 Untrusted Code<br/><i>python · node · bash</i>"]
    end

    PG[("🗄️ PostgreSQL 16<br/><i>execution_runs</i>")]
    RD[("📮 Redis 7 Queue<br/><i>sandbox:jobs</i>")]

    CLI -->|"POST /api/v1/execute"| API
    API -->|"validate + acquire"| POOL
    POOL -->|"spawn + limits"| RUN
    RUN -.->|"apply jail"| ISO
    ISO ==>|"seccomp · pivot_root"| GUEST
    RUN -->|"fork / exec"| INIT
    INIT -->|"syscall.Exec"| GUEST
    RUN -.->|"stdout / stderr ≤ 512 KB"| POOL
    API -.->|"async audit INSERT"| PG
    RD -.->|"BRPop drain · worker module"| POOL

    style JAIL fill:#2a1215,stroke:#f87171,stroke-width:2px
    style CP fill:#0d1b2a,stroke:#38bdf8,stroke-width:1px

Décomposition des composants

ComposantResponsabilitéSource
Démon d'ingestionSurface REST : POST /api/v1/execute + /health ; validation des requêtes ; émission d'audit asynchronecmd/server/main.go
Pool de runners préchauffésEmplacements d'exécution bornés par sémaphore (16) avec un délai d'acquisition de 3 s → backpressure d'épuisement de type 503internal/runner/pool.go
Runner de processusConstruit la commande du langage, attache le cgroup, diffuse les pipes via des writers tronquants, applique le watchdog de 5 s, collecte les métriques du cgroup, classe les résultatsinternal/runner/process.go
Isolation du noyauLimiteur cgroups v2 (memory.max, cpu.max, pids.max), drapeaux de namespaces (CLONE_NEWPID/NET/NS/IPC/UTS/USER), compilateur de filtres seccomp-BPFinternal/isolation/
sandbox_initTrampoline enfant : pivot_root en lecture seule + tmpfs /dev//tmp, détachement réseau (lo désactivé), application de seccomp, puis syscall.Exec de la ciblecmd/sandbox_init/main.go
Code non fiableLa charge utile invitée. Périphériques hôtes retirés, /proc masqué (hidepid=2), tous les appels système non autorisés tuésimages rootfs runtimes/
PostgreSQL 16Journal d'audit durable de chaque exécution, y compris les violations de sécuritémigrations/001_init_sandbox_schema.sql
Redis 7File sandbox:jobs + worker BRPop drainant vers le pool (module implémenté, pas encore câblé dans le démon — voir Limitations connues)internal/queue/redis_consumer.go

Frontières de confiance

FrontièreCe qu'elle sépareApplication
Client ↔ DémonSoumission de charge utile non authentifiée depuis le plan de contrôlevalidation de schéma (tenant_id, language, code)
Plan de contrôle ↔ PrisonCode Go de confiance vs. charge utile hostilefork dans des namespaces privés ; pivot_root ; seccomp hérité à l'exécution
Prison ↔ Limites du noyauConsommation de ressources de l'invité vs. capacité de l'hôtecgroups v2 memory.max=128MB, swap.max=0, cpu.max="50000 100000", pids.max=32
Prison ↔ RéseauToute sortie ou accessibilité côté hôtenamespace NET privé, lo désactivé, appel système socket tué

🔍 Une version interactive et adaptée au thème de ce diagramme (avec export PNG/SVG) est générée à partir des candidats étayés par des preuves dans docs/archify/.


Cycle de vie d'exécution — De la requête à l'audit

sequenceDiagram
    autonumber
    participant C as Client
    participant A as REST API
    participant P as Warm Pool
    participant R as Process Runner
    participant I as sandbox_init
    participant G as Untrusted Code
    participant DB as PostgreSQL
Télécharger l’outil