Příklady zásad MXC

Tyto příklady ukazují, jak se požadavky na pracovní zátěž překládají do oprávnění prostředků MXC. Můžete začít rychlým startem pro C#, TypeScript nebo Rust a pak přizpůsobit konfiguraci vaší úloze.

Níže uvedený kód JSON používá strukturu nezpracované konfigurace spuštění pro schéma MXC 1.0.0. Úplné konfigurace zahrnují verzi a příkaz; oddíly označené jako fragmenty musí být začleněny do stávající konfigurace. Při vytváření v jazyce C#, TypeScript nebo Rust použijte odpovídající typy sady SDK V1, které nevyžadují konkrétní verzi schématu.

Toto jsou příklady Windows. Cesty nahraďte existujícími zdroji na hostiteli, udělte jakékoli další závislosti nástrojů záměrně a potvrďte, že vaše verze sady SDK a back-end podporují vybrané ovládací prvky.

Spuštění nástroje omezeného na úložiště

Tato úplná konfigurace používá stejný vzor read-input/write-output jako rychlý start. Před spuštěním vytvořte C:\src\my-app\input.txt a adresář C:\src\mxc-output. Příkaz může číst zdrojový adresář a zapisovat do výstupního adresáře, ale nemůže zapisovat do zdrojového adresáře ani používat síť nebo uživatelské rozhraní.

{
  "$schema": "https://raw.githubusercontent.com/microsoft/mxc/main/schemas/stable/mxc-config.schema.1.0.0.json",
  "version": "1.0.0",
  "containment": "process",
  "process": {
    "commandLine": "C:\\Windows\\System32\\cmd.exe /d /c type input.txt > C:\\src\\mxc-output\\result.txt",
    "cwd": "C:\\src\\my-app",
    "env": [
      "SystemRoot=C:\\Windows",
      "LOCALAPPDATA=C:\\src\\mxc-output",
      "TEMP=C:\\src\\mxc-output",
      "TMP=C:\\src\\mxc-output"
    ],
    "timeout": 30000
  },
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app", "C:\\Windows\\System32\\cmd.exe"],
    "readwritePaths": ["C:\\src\\mxc-output"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "injection": false
  }
}

V tomto příkladu se předpokládá, že Windows je nainstalován v C:\Windows; použijte skutečný systémový adresář na vašem hostiteli. Požadavek ProcessContainer Windows s explicitním env seznamem musí obsahovat obojí SystemRoot i LOCALAPPDATA. Když příkaz nahradíte nástrojem pro sestavení nebo analýzu, nakonfigurujte jeho mezipaměti a dočasné soubory tak, aby používaly vyhrazený zapisovatelný adresář namísto udělení přístupu k zápisu k celému úložišti.

Chraňte přihlašovací údaje v širším oprávnění

Předchozí konfigurace uděluje přístup pro čtení k C:\src\my-app. Pokud tento adresář obsahuje soubor prostředí nebo adresář secrets, přidejte tento fragment do jeho existujícího filesystem oddílu a zachovejte seznamy jen pro čtení a zápis:

{
  "deniedPaths": [
    "C:\\src\\my-app\\.env",
    "C:\\src\\my-app\\secrets"
  ]
}

Tyto odepřené cesty jsou uvnitř povoleného zdrojového adresáře. Uchovávejte nesouvisející úložiště a adresáře profilů uživatelů mimo oprávnění.

Pokud je to možné, uchovávejte tajné údaje mimo stromy oprávnění. Ověřte překrývající se povolení a odepření ve vybraném backendu; některé backendy pro připojený adresář odmítají vnořená odepření místo aby je vynucovaly.

Povolit přímý přístup k rozsahu IP adres

Tento fragment konfigurace nahrazuje network oddíl. Povoluje odchozí port TCP 443 do schváleného rozsahu CIDR a odepře další odchozí, příchozí a přístup k loopbacku hostitele. Poskytujte schválené rozsahy z důvěryhodné konfigurace spíše než je přijímat z úlohy.

{
  "network": {
    "egress": {
      "default": "deny",
      "allow": [
        {
          "to": [{ "cidr": "192.0.2.0/24" }],
          "ports": [{ "protocol": "tcp", "port": 443 }]
        }
      ]
    },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  }
}

192.0.2.0/24 je rozsah jen pro dokumentaci. Nahraďte ji schválenými adresami určené služby. Pravidlo povoluje protokol TCP na daném portu, nikoli výhradně pro HTTPS, jeden název hostitele nebo jednu aplikační službu. Přímé rozlišení názvu hostitele může vyžadovat samostatné pravidlo DNS.

Tento příklad vyžaduje backend a hostitele, který podporuje pravidla přímé odchozí komunikace. Nekombinujte to s ním runtimeConfig.networkProxy. Pro rozhodnutí HTTP(S) na základě názvu hostitele použijte místo toho podporovanou konfiguraci založenou na proxy serveru.

Použít proxy server poskytnutý aplikací

Před spuštěním úlohy musí vaše hostitelská aplikace spustit svůj proxy server. Tento příklad konfiguruje MXC tak, aby používal existující proxy server; neimplementuje, nespouští ani neschvaluje zásady zpracování požadavků proxy serveru.

Následující fragment konfigurace cílí na Windows ProcessContainer s podporovanou cestou vynucení proxy serveru na úrovni operačního systému. Sloučit ho do úplné konfigurace, zachovat příkaz, oprávnění systému souborů, časový limit a omezení uživatelského rozhraní. Nahraďte koncový bod a název protějšku hodnotami vašeho spuštěného proxy serveru.

{
  "containment": "processcontainer",
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "allow", "hostLoopback": "deny" }
  },
  "runtimeConfig": {
    "networkProxy": "http://127.0.0.1:8080"
  },
  "processContainer": {
    "network": {
      "allowedProxyPeer": "<package-family-name-or-appcontainer-profile-name>"
    }
  }
}

allowedProxyPeer identifikuje nainstalovaný balíček proxy nebo nebalíčkový profil AppContainer. Proxy musí naslouchat nakonfigurované adrese zpětné smyčky a portu a splňovat zdokumentované předpoklady pro Windows. MXC neodvozuje z adresy URL danou identitu.

Important

Toto mapování Windows vyžaduje ingress.default: "allow", což také umožňuje provoz serveru v privátní síti. hostLoopback: "deny" udržuje obecný přístup ke zpětné smyčce hostitele zavřený, zatímco nakonfigurovaný partner proxy serveru je dostupný. Tento příklad není konfigurace, která zakazuje všechna příchozí připojení.

Přímý přístup k internetu zůstává na cestě vynucování odepřen. Proxy určuje, které požadavky HTTP(S) přeposílá. Prostý rozbalený proxy hostitel bez identity AppContainer potřebuje jinou, širší konfiguraci kompatibility; neodstraňujte allowedProxyPeer a nepředpokládejte, že zůstávají stejná omezení.

Použijte odpovídající typy sad SDK a ověřte podporu před tím, než se spoléháte na přístup pouze přes proxy. Požadavky pro Windows najdete v tématu Volby nasazení proxy serveru ProcessContainer a pro ostatní back-endy v tématu směrování sítě.

Povolit viditelný nástroj bez širokého přístupu k uživatelskému rozhraní

Pro zátěž, která potřebuje viditelné okno a vstup ze schránky, tento fragment konfigurace nahrazuje ui. Umožňuje čtení oken a schránky, ale ne zápisy do schránky nebo syntetický vstup z klávesnice a ukazatele:

{
  "ui": {
    "disable": false,
    "clipboard": "read",
    "injection": false
  }
}

V sadě SDK ContainerRequestV1 jsou disableekvivalentní vlastnosti uživatelského rozhraní , clipboarda allowInputInjection. Povolte čtení ze schránky jen v případech, když to úloha vyžaduje. Zkontrolujte podporu běhového uživatelského rozhraní a otestujte požadovaná omezení na každém cílovém hostiteli.

Opakované použití stavového sandboxu

Spouštění s podporou stavu použijte, když příkazy musí sdílet prostředí. Zřiďte ho a spusťte ho, spusťte příkazy a po dokončení ho zastavte a zrušte ho. Nastavte vyčištění po selhání a zrušení, nejen po úspěchu.

Volání s podporou stavu používají pro každý příkaz ProvisionRequest specifickou pro danou fázi a samostatnou ExecutionRequest, nikoli úplnou jednorázovou konfiguraci uvedenou výše. Zřizování vrátí neprůhledný objekt ContainerId; předejte ho beze změny do pozdějších fází. Použijte MxcLifecycle v .NET, funkce životního cyklu TypeScriptu, jako jsou provisionContainer, nebo funkce Rustv1::container, jako jsou provision_container, s IsolationSession nebo WSLc, back-endy, které rozhraní API životního cyklu V1 podporují. Přesné požadavky najdete v konceptech životního cyklu, životním cyklu kontejneru MXC a v průvodci sadou SDK pro .NET, TypeScript nebo Rust.

Než zvolíte, zkontrolujte, co jednotlivé backendy životního cyklu vynucují. IsolationSession odděluje uživatele a relaci úlohy, ale nepoužívá systém souborů MXC, uživatelské rozhraní nebo filtrování sítě a jeho požadavek musí explicitně povolit veškerý síťový provoz. Sítě WSLc jsou buď plně izolované, nebo plně přemostěné, bez pravidel pro jednotlivé cíle. Podrobnosti najdete v tématech Výběr typu kontejneru a Výběr a nastavení back-endu.

Ověřte příklady

Pro každou upravenou zásadu otestujte zamýšlené chování i pokus o zneužití:

  • Ověřte, že je možné číst požadované vstupy a zapisovat požadované výstupy.
  • Ověřte, že přihlašovací údaje a nesouvisející soubory zůstanou nedostupné.
  • Ověřte, že přímá, připojení v místní síti, loopback připojení a příchozí připojení odpovídají zásadám.
  • V případě přístupu na základě proxy serveru ověřte, že schválený požadavek proběhne úspěšně a že přímý pokus o přístup k internetu selže.
  • Ověřte, že schránka, injektáž vstupu a viditelná okna odpovídají zásadám uživatelského rozhraní.
  • Ověřte, že po úspěchu, selhání a zrušení fungují vypršení časového limitu a vyčištění.

Pomocí Learning Mode můžete prošetřit chybějící přístup. Neudělujte automaticky oprávnění ke každému prostředku, který pozoruje běh zástupce.

Související obsah

  • Poslední aktualizace v