Di recente il team di Podman ha ricevuto un rapporto Bugzilla in cui si affermava che non c'era modo di impedire a Podman rootless di eseguire container. Il segnalatore imposta un account utente senza voci in /etc/subuid e /etc/subgid e ha riferito che Podman senza root potrebbe ancora eseguire hello-world contenitore.
Ipotesi errata
Rimozione delle informazioni utente da /etc/subuid non impedisce agli utenti di utilizzare Podman. Diamo un'occhiata più a fondo a cosa succede quando qualcuno usa Podman senza root per eseguire un container.
Innanzitutto, renditi conto che le immagini del contenitore come hello-world sono solo tarball insieme ad alcuni contenuti JSON che si trovano su un server web chiamato registro di immagini del contenitore. Qualsiasi applicazione in grado di comunicare con un server Web può eliminarli utilizzando protocolli Web standard e strumenti come curl .
Quando Podman tira giù un'immagine, prima crea e inserisce uno spazio dei nomi utente. Questo spazio dei nomi utente di solito associa l'UID dell'utente alla radice (UID=0) all'interno dello spazio dei nomi utente. Quindi cerca in /etc/subuid per l'utente e utilizza gli UID qui elencati per popolare il resto degli UID disponibili all'interno dello spazio dei nomi utente. Fa lo stesso per i gruppi tramite /etc/subgid . Se non ci sono voci in /etc/subuid e /etc/subgid , quindi lo spazio dei nomi utente è costituito solo dall'UID dell'utente mappato come root. Una volta impostato lo spazio dei nomi utente, Podman estrae il contenuto tar dell'immagine. Se l'immagine ha file di proprietà di utenti diversi da UID=0, Podman estrae e tenta di chown il contenuto all'utente e al gruppo definiti. Se l'utente e il gruppo non sono definiti all'interno dello spazio dei nomi utente, allora il chown fallisce e Podman fallisce.
Nell'esempio Bugzilla, il giornalista ha tentato di eseguire hello-world .
$ podman run hello-world
Resolved "hello-world" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull docker.io/library/hello-world:latest...
Getting image source signatures
Copying blob b8dfde127a29 done
Copying config d1165f2212 done
Writing manifest to image destination
Storing signatures
Hello from Docker!
…
Ha funzionato anche se l'utente non aveva voci in /etc/subuid e /etc/subgid .
Entriamo nello spazio dei nomi utente e vediamo cosa sta succedendo.
Podman unshare cat /proc/self/uid_map
0 3267
Avviso, il mio account è configurato senza accesso in /etc/subuid . Podman sta mappando il mio UID 3267 su UID 0 per un intervallo di un UID. Ora diamo un'occhiata al contenuto dell'immagine del contenitore hello-world . Inserisci lo spazio dei nomi utente, monta il hello-world immagine ed elenca il contenuto.
$ podman unshare
# mnt=$(podman image mount hello-world)
# ls -l $mnt
total 16
-rwxrwxr-x. 1 root root 13336 Mar 5 18:25 hello
Nota che l'unico contenuto è hello comando. Questo è un binario GO collegato staticamente, di proprietà di root all'interno dello spazio dei nomi utente e UID=3267 nella mia home directory.
Questo è il motivo per cui il comando ha funzionato, anche senza UID e GID aggiuntivi.
Proviamo a eseguire un'immagine contenitore con più di un UID.
$ podman run fedora echo hi
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob 7679c09af385 done
Copying config 3567369c67 done
Writing manifest to image destination
Storing signatures
Error: Error committing the finished image: error adding layer with blob "sha256:7679c09af3851a1622782c74864351c296a0d1886813862fd7116383aeba9f07": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:12 for /var/spool/mail): Check /etc/subuid and /etc/subgid: lchown /var/spool/mail: invalid argument
Nota che Podman può tirare giù i tarball (si riferisce a loro come blob). Quando tenta di estrarli, fallisce quando tenta di chown il /var/spool/mail directory in un GID (12) non definito all'interno dello spazio dei nomi utente e il contenitore non riesce.
Linea inferiore
L'esecuzione di contenitori senza privilegi è sicura e non può influire sul sistema più del semplice accesso al sistema. L'utente Podman esegue attività che gli utenti normali possono eseguire:estrarre il contenuto dai server Web e decomprimerli. Infine, gli utenti possono persino eseguire il contenuto. Gli unici errori si verificano quando l'utente tenta di passare a UID non consentiti all'utente tramite comandi come chown o su .
Nell'esempio sopra, Podman non ha fatto nulla che richiedesse privilegi extra. Tutti i processi eseguiti tramite Podman dall'utente erano soggetti agli stessi vincoli di qualsiasi processo utente. In realtà, sono più vincolati poiché sono racchiusi con SELinux, SECCOMP e altri meccanismi di sicurezza.
L'utilizzo di Podman senza root per eseguire un'immagine contenitore non è meno sicuro che consentire agli utenti di scaricare file eseguibili da un server Web ed eseguirli nella loro home directory.
Se desideri comunque impedire a determinati utenti di un sistema di eseguire Podman, devi modificare le autorizzazioni su Podman stesso.
# chmod 750 /usr/bin/podman
# groupadd podman
# chown root:podman /usr/bin/podman
Aggiungi gli utenti a cui desideri consentire l'accesso a Podman al gruppo podman. Renditi conto solo che quando Podman verrà aggiornato, dovrai eseguire il chmod e chown comandi di nuovo e rpm -qV podman segnalerà problemi con l'installazione.
Credito extra
Per gli utenti avanzati, in particolare le persone in High-Performance Computing (HPC), abbiamo aggiunto un flag speciale, ignore_chown_errors , allo spazio di archiviazione del contenitore.
man storage.conf
…
ignore_chown_errors = "false"
ignore_chown_errors can be set to allow a non privileged user running with a single UID within a user namespace to run containers. The user can pull and use any image, even those with multiple uids. Note multiple UIDs will be squashed down to the default uid in the container. These images will have no separation between the users in the container. (default: false)
Impostando questo flag in /etc/containers/storage.conf di $HOME/.config/containers/storage.conf a true, Podman può eseguire correttamente il contenitore Fedora.
$ grep ignore_chown_err /etc/containers/storage.conf
# ignore_chown_errors can be set to allow a non privileged user running with
ignore_chown_errors = "true"
$ podman unshare cat /proc/self/uid_map
0 3267 1
$ podman run fedora echo hi
Resolved "fedora" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.fedoraproject.org/fedora:latest...
Getting image source signatures
Copying blob 7679c09af385 done
Copying config 3567369c67 done
Writing manifest to image destination
Storing signatures
hi
Questa volta quando Podman ha tentato di chown il /var/spool/mail directory e ha ricevuto un errore, lo ha ignorato e ha continuato. HPC non desidera che gli utenti abbiano più di un UID, quindi ciò consente ai loro utenti di eseguire immagini OCI standard ma non devono allentare affatto le loro impostazioni di sicurezza. Nota che funziona correttamente purché l'unico UID che esegui all'interno del contenitore sia la radice del contenitore. Se, per qualsiasi motivo, il processo tenta di modificare l'UID in un UID non definito all'interno del contenitore, non riuscirà. Inoltre, nella maggior parte dei casi, tutti i file nell'immagine saranno di proprietà dell'utente. L'utente del contenitore dispone delle autorizzazioni di lettura/scrittura complete su tutto il contenuto.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]
Concludi
Gli amministratori Podman devono essere consapevoli di quali livelli di accesso vengono concessi. Assicurati di aver compreso l'intento e la funzione di /etc/subuid e /etc/subgid e come influiranno sulla sicurezza dei container.
Infine, usa ignore_chown_errors opzione con cura. È stato progettato per scenari HPC.