Jednou z nejzajímavějších nových funkcí aplikace Podman jsou kontejnery bez kořenů. Rootless umožňuje spouštět téměř jakýkoli kontejner jako normální uživatel bez zvýšených oprávnění a velkých bezpečnostních výhod. Spouštění kontejnerů bez oprávnění root však přináší omezení.
Uživatel se zeptal na jednu z těchto otázek:Proč nemohli vytáhnout konkrétní obrázek s Podmanem bez kořenů?
Jejich obrázek po stažení házel chyby, jako je ten níže:
ERRO[0005] Error pulling image ref //testimg:latest: Error committing the finished image: error adding layer with blob "sha256:caed8f108bf6721dc2709407ecad964c83a31c8008a6a21826aa4ab995df5502": Error processing tar file(exit status 1): there might not be enough IDs available in the namespace (requested 4000000:4000000 for /testfile): lchown /testfile: invalid argument
Vysvětlil jsem, že jejich problém byl v tom, že jejich obrázek měl soubory vlastněné UID přes 65536. Kvůli tomuto problému by se obrázek nevešel do výchozího mapování UID Podman bez root, což omezuje počet dostupných UID a GID.
Následné otázky byly přirozeně:
- Proč toto omezení existuje?
- Proč nemůžete použít žádný obrázek, který funguje na normálním Podmanu v režimu bez kořenů?
- Proč jsou přesná používaná UID a GID důležitá?
Začnu vysvětlením, proč potřebujeme používat jiné UID a GID než hostitel, a poté vysvětlím, proč je výchozí hodnota 65536 – a jak toto číslo změnit.
Mapování jmenného prostoru uživatele
Kontejnery bez root běží uvnitř jmenného prostoru uživatele , což je způsob mapování uživatelů a skupin hostitele do kontejneru. Ve výchozím nastavení mapujeme uživatele, který spustil Podman, jako UID/GID 0 v kontejnerech bez kořenů.
V mém systému můj uživatel (mheon ) je UID 1000. Když spustím kontejner bez kořenů jako mheon pomocí podman run -t -i --rm fedora bash a poté spusťte top uvnitř kontejneru se zdá, že jsem UID 0 – root.
Na hostiteli však bash proces je stále ve vlastnictví mého uživatele. Tento výsledek můžete vidět, když spustím podman top na mém hostitelském systému:
mheon@Agincourt code/podman.io (release_blog_1.5.0)$ podman top -l user group huser hgroup
USER GROUP HUSER HGROUP
root root 1000 1000
USER a GROUP možnosti jsou uživatel a skupina, jak se objevují v kontejneru , zatímco HUSER a HGROUP možnosti jsou uživatel a skupina, jak se zobrazují na hostiteli .
Ukažme si jednoduchý příklad. Připojím /etc/ , který je plný souborů vlastněných rootem, do kontejneru bez kořenů. Poté ukážu jeho obsah pomocí ls :
mheon@Agincourt code/libpod (master)$ podman run -t -i -v /etc/:/testdir --rm fedora sh -c 'ls -l /testdir 2> /dev/null | head -n 10'
total 1700
-rw-r--r--. 1 nobody nobody 4664 May 3 14:39 DIR_COLORS
-rw-r--r--. 1 nobody nobody 5342 May 3 14:39 DIR_COLORS.256color
Nemám oprávnění tyto soubory měnit, přestože jsem root v kontejneru. Mnoho z nich ani nevidím:Všimněte si 2> /dev/null za ls squash chyby, protože mám mnoho chyb oprávnění, i když se je snažím vypsat.
Na hostiteli jsou tyto soubory vlastněny rootem, UID 0 – ale v kontejneru je nevlastní nobody . Toto je speciální jméno, které linuxové jádro používá, aby řeklo, že uživatel, který skutečně vlastní soubory, není přítomen v uživatelském jmenném prostoru. UID a GID 0 na hostiteli nejsou namapovány do kontejneru, takže místo toho, aby soubory vlastnil 0:0 , jsou vlastněny nobody:nobody z pohledu kontejneru.
Bez ohledu na to, jaký uživatel se může zdát v kontejneru bez rootu, stále jednáte jako svůj vlastní uživatel a máte přístup pouze k souborům, ke kterým má přístup váš uživatel na hostiteli. Toto nastavení je velkou součástí bezpečnostní přitažlivosti kontejnerů bez root – i když se útočníkovi podaří proniknout z kontejneru, stále je omezen na uživatelský účet bez oprávnění root.
Přidělení dalších UID/GID
Již dříve jsem řekl, že uživatelský jmenný prostor mapuje uživatele na hostiteli na uživatele v kontejneru a popsal jsem trochu, jak tento proces funguje pro root v kontejneru. Ale kontejnery mají obecně jiné uživatele než jen root – což znamená, že Podman potřebuje namapovat další UID, aby umožnil uživatelům jednoho a výše v kontejneru existovat.
Jinými slovy, každý uživatel požadovaný kontejnerem musí být namapován. Tento problém způsobil výše uvedenou původní chybu, protože obrázek používal UID/GID, který nebyl definován v jeho uživatelském jmenném prostoru.
newuidmap a newgidmap spustitelné soubory, obvykle poskytované shadow-utils nebo uidmap balíčky, se používají k mapování těchto UID a GID do prostoru uživatelských jmen kontejneru. Tyto nástroje čtou mapování definovaná v /etc/subuid a /etc/subgid a použít je k vytvoření uživatelských jmenných prostorů v kontejneru. Tyto setuid binární soubory používají přidaná oprávnění, aby umožnily našim bezkořenovým kontejnerům přístup k dalším UID a GID – k něčemu, k čemu normálně nemáme oprávnění. Každý uživatel, který používá rootless Podman, musí mít v těchto souborech záznam, pokud potřebuje spouštět kontejnery s více než jedním UID. Každý kontejner používá všechna standardně dostupná UID, i když přesná mapování lze upravit pomocí --uidmap a --gidmap .
Normální uživatel bez oprávnění root má v Linuxu obvykle přístup pouze ke svému vlastnímu uživateli – jednomu UID. Použití dalších UID a GID v kontejneru bez root vám umožní jednat jako jiný uživatel, něco, co normálně vyžaduje oprávnění root (nebo se přihlásit jako jiný uživatel pomocí svého hesla). Mapovací spustitelné soubory newuidmap a newgidmap pomocí jejich zvýšených oprávnění nám udělují přístup k dalším UID a GID podle mapování nakonfigurovaného v /etc/subuid a /etc/subgid aniž byste byli root nebo měli oprávnění přihlásit se jako uživatelé.
Každý uživatel používající rootless Podman musí mít v těchto souborech záznam, pokud potřebuje spouštět kontejnery s více než jedním UID uvnitř.
Změna výchozího počtu ID
Nyní k problému výchozího počtu UID a GID dostupných v kontejneru:65536. Toto číslo není pevný limit a lze jej upravit nahoru nebo dolů pomocí výše uvedeného /etc/subuid a /etc/subgid soubory.
Například v mém systému:
mheon@Agincourt code/libpod (master)$ cat /etc/subuid
mheon:100000:65536
Tento soubor je naformátován jako <username>:<start_uid>:<size> , kde start_uid je první UID nebo GID dostupné uživateli a size je počet dostupných UID/GID (počínaje start_uid a končí na start_uid + size - 1 ).
Kdybych nahradil těch 65536 řekněme 123456, měl bych v kontejnerech bez kořenů k dispozici 123456 UID.
"Proč zvolit 65536 jako výchozí?" je otázka pro správce linuxového nástroje pro vytváření uživatelů useradd , protože výchozí výchozí hodnoty jsou vyplněny při vytvoření uživatele, nikoli Podmanem. Budu však riskovat, že toto nastavení stačí k tomu, aby většina aplikací fungovala beze změn (velmi staré verze Linuxu měly pouze 16bitové UID/GID a vyšší hodnoty jsou stále poněkud neobvyklé).
Poznámka: /etc/subuid a /etc/subgid soubory jsou pro úpravu uživatelů, kteří již existují. Výchozí hodnoty pro nové uživatele jsou upraveny jinde.
Výchozí hodnota 65536, kterou obdrží noví uživatelé, není pevně zakódována. To však neovlivní stávající uživatele. Nastavuje se v /etc/login.defs soubor s SUB_UID_COUNT a SUB_GID_COUNT možnosti. Ve skutečnosti jsme vedli diskuse o posunutí výchozího nastavení níže, protože se zdá, že většina kontejnerů bude pravděpodobně fungovat dobře s něco málo přes 1000 UID/GID a další poté jsou zbytečné.
Důležité je, že tato hodnota představuje úsek UID/GID přidělených na hostiteli, které jsou dostupné pro jednoho konkrétního uživatele pro spouštění bezkořenových kontejnerů. Pokud bych do tohoto systému přidal dalšího uživatele, dostali by další trakt UID, pravděpodobně začínající na 165536, opět 65536 na šířku ve výchozím nastavení.
Root má oprávnění ke změně těchto limitů, ale normální uživatelé ne. Jinak bych mohl trochu změnit mapování na mheon:0:65536 a namapovat skutečného uživatele root v systému do mých bezkořenových kontejnerů, které pak lze snadno převést na systémový root přístup.
Zabránění překrývání UID a GID
Obecným pravidlem pro bezpečnost je, že nevkládejte do kontejneru žádné systémové UID/GID (obvykle číslované do 1000) a ideálně jakékoli UID/GID používané v hostitelském systému. Tento postup zabraňuje uživatelům v přístupu k systémovým souborům na hostiteli, když vytvářejí kontejnery bez kořenů.
Chceme také, aby každý uživatel měl jedinečný rozsah UID/GID vzhledem k ostatním uživatelům – mohl bych přidat uživatele alice do mého /etc/subuid se stejným mapováním jako můj uživatel (alice:100000:65536 ), ale pak by Alice měla přístup k mým kontejnerům bez kořenů a já k jejím.
Je možné zvýšit velikost alokace vašeho uživatele, jak bylo uvedeno výše, ale z důvodu zabezpečení musíte dodržovat tato pravidla. Uvedu je znovu:
- Žádné UID/GID pod 1000.
- Žádné UID ani GID nevstoupí do kontejneru, pokud se používá na hostiteli.
- Nepřekrývají se mapování mezi uživateli.
Poslední je primární důvod, proč nechceme mapovat ve vyšších alokacích UID a GID. Potenciálně bychom mohli dát jednomu uživateli obrovský rozsah, včetně všeho od 100 000 až po UID_MAX a zpřístupnit něco málo přes 4,2 milionu UID – ale pak by nezbylo žádné pro ostatní uživatele.
Zabalení
S Podmanem 1.5.0 a vyšším jsme přidali novou, experimentální možnost (--storage-opt ignore_chown_errors ) stlačit všechna UID a GID, čímž kontejnery spustíte jako jediný uživatel (uživatel, který kontejner spustil). Toto nastavení řeší počáteční problém článku, ale klade na kontejner řadu dalších omezení – podrobnosti o tom je lepší ponechat v jiném článku.
Omezení UID a GID umístěná na kontejnery bez kořenů mohou být nepohodlná, ale jen zřídka na ně narazíte. Většina obrázků a kontejnerů používá mnohem méně než 65536 dostupných UID a GID. Tato omezení jsou některými z kompromisů kontejnerů bez kořenů, kde obětujeme určité pohodlí a použitelnost pro zásadní zlepšení zabezpečení.