nesting (Proxmox CT-ben)

Virtualizáció

Sziasztok!

Proxmox 7-ben Container létrehozásakor a webes felületen alapértelmezésben be van pipálva a Nesting. Az Linux Container - Proxmox VE oldalon szereplő leírás szerint a nesting=0 alapértelmezett értékkel rendelkezik. Olvasgattam további leírásokat is de elbizonytalanodtam, hogy szükséges-e bejelölve hagyni a Nesting-et.

  1. Ha a Proxmox-on létrehozandó Linux Container-ben nem akarok Docker-t és további (Linux) konténereket futtatni (csak egy standard Debian 11-es webszervert), akkor jól olvastam ki a leírásokból, hogy fölösleges engedélyeznem a nesting-et egy Proxmox Container-ben?
  2. Ha mégis bekapcsolom a nesting-et a Proxmox Container-ben, és megtörik a benne futó webszervert, akkor hozzáférhetnek a Proxmox host-hoz is?
  • 278 megtekintés

( gabrielakos v | 2022. 12. 10., szo – 16:51 )

1. jól olvastad
2. önmagában a nesting miatt nem törik fel, más miatt persze nem kizárható

zászló, zászló, szív

Lehet, hogy nem fogalmaztam egyértelműen a 2. kérdésemben, ezért átfogalmazom.

2. Ha a webszerveren keresztül bejutnak a Proxmox Container-re, akkor nagyobb eséllyel "férnek hozzá" (jutnak be, törik fel) a host OS-hez, ha engedélyezve van a nesting?

Amit nem írtam eddig, hogy unprivileged container-ről van szó.

( gyuri23 | 2022. 12. 10., szo – 19:23 )

Szerkesztve: 2022. 12. 10., szo – 19:25

Ezt mások is kérdezték, a gyártó válasza, mert a PMG konténernél is be kell kapcsolni:

https://forum.proxmox.com/threads/pmg-lxc-container-question-about-nest…

PMG 6.x was based on debian buster and had thus an older version of systemd packaged then 7.x which is based on debian bullseye.
newer versions of systemd need access to proc in order to do their own isolation of unit's

since your PMG container is unprivileged enabling nesting should not pose a too large security risk (a regular user on your system can also not elevate their privileges by having access to /proc and /sys)

I hope this explains it!

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

  1. Jól értem? Tehát PVE 7-től kezdve (pl. a megfelelő futási sebesség elérése érdekében is) már olyan konténerek esetén is be kell kapcsolni a nestinget, amelyek nem használnak dockert vagy Linux konténert a konténeren belül?
  2. Vagy a PMG 7 pl. dockert használ, és azért van szükség a nesting engedélyezésére?
  3. Ha illetéktelenek bejutnak a konténerbe, és a konténerben (map-pelt) root jogot szereznek, akkor a host OS annak ellenére "nincs veszélyben", hogy a host /proc és /sys mappái rw módon vannak "felcsatolva" (mert elvileg úgy vannak) a konténerbe?

Az alábbi linken lévő bejegyzés valószínűleg még PVE 6-ra vonatkozik (a PVE 7 kiadása után egy hónappal tették közzé)? Mert ebben még mást írnak.

https://forum.proxmox.com/threads/question-on-nested-option-lxc-contain…

"Nesting is disabled by default, so what is the advantage to enabling it in a trusted environment, eg in a home-LAN?"

it does not bring any advantage unless you want to run docker or other container technologies in LXC.
there are also some usecases with different software utilizing chroots (they won't work in containers without nesting in some cases)

Igen úgy tűnik be kell kapcsolni. PVE 7-en futó debian 11 konténerbe volt vagy 2 perc míg megkaptam a shell-t, akkor olvastam, hogy a nesting hiánya az ok. Érdekes, hogy utána nem tapasztaltam lassulást.
A PMG 7 nem használ dockert, és nesting sem kell neki, pedig debian 11 az is. Még nem jöttem rá, mit piszkált bele a proxmox, hogy az meg megy rendesen, mert a "sima" debian konténernél én tapasztaltam a problémát.
Elvileg az unprivileged konténerél nem lehet gond, mert ott ha kijut a root a konténerből, a hoston nincs root joga. Persze ez elmélet, a proxmox-osok is így fogalmaztak:  nesting should not pose a too large security risk, a gyakorlatban meg vmware-t is törtek már meg guest-ből...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( ggallo | 2022. 12. 11., v – 09:24 )

Én nem mélyedtem bele ennyire tudományosan, csak tapasztalati alapon írom, hogy modernebb guest OS-t futtatva a systemd nem örül, ha nincs a nesting bekapcsolva. Csináltam egy Debian 11 CT-t (Proxmox 6.4 host), burp-ot tesztelni. Elképesztő lassú belépés jelentkezett úgy konzolon, mint SSH-n keresztül. Meg valami hiba is előkerült, de már nem emléxem mi volt az üzenet. Ezen a kettőn elindulva első 1-2 találat között a Proxmox fórumban olvatsam, hogy a nesting bekapcsolása lesz a megoldás, és úgy is lett. Bekapcsoltam, jó lett. Nem olvastam utána alaposabban, miért...

Ha esetleg van most telepített Debian 11 konténered, kérlek megnéznéd, hogy mi az alábbi parancs kimenete a konténer elindítása / újraindítása után?

systemctl status ssh.service

Normális, hogy nálam az alábbi a kimenet?

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:sshd(8)
             man:sshd_config(5)

Ennek ellenére be tudok lépni ssh-n. Ha a konténerben elindítom az ssh szolgáltatást, akkor azt mutatja, hogy running, de a konténer újraindítása után újra inaktív lesz, de továbbra is beenged ssh-n.

Annyi még hozzátartozik a történethez, hogy a Debian 11 konténer létrehozásakor nem töltöttem fel SSH kulcsot, hanem később konfigurálgattam még egy kicsit a konténerben a /etc/ssh/sshd_config fájt és feltöltöttem a kulcsot is.

( veresh | 2022. 12. 16., p – 21:07 )

Köszönöm, hogy foglalkoztatok a kérdésemmel, és időt számtatok rá.