Miért nem fut minden konténerben, izoláltan? Miért nincs ilyen OS-kezdeményezés?

Virtualizáció

Nagyon keveset értek a témához, de kíváncsi vagyok.

Annak idején webes frontend fejlesztőként praktikusnak találtam, hogy Dockerben futtattuk az applikációkat, mert így félreértések nélkül lehetett dolgozni új feature-ökön és tesztelhettünk különböző verziókat. Kis gyakorlás után nem volt nagy ügy egy Dockerfile összeállítása, és tisztább, szárazabb, jobb érzést nyújtott ez a munkamódszer.

Mostanában játékprogram-fejlesztéssel kísérletezem, és egyik visszatérő probléma, hogy ha ismerősöket kérek meg a fejlesztések kipróbálására, a Windowsuk pánikol az internetről letöltött játékprogram miatt (a Macen meg alapból notarizálni kell mindent, ami szerencsére elfogadható sebességű folyamat). Persze, vannak módszerek, amivel "megbízhatóbbá" lehet tenni egy programot (be lehet jelenteni az adott verziót a Microsoftnak, és akkor a következő Defender frissítéssel amiatt a verzió miatt már nem fog reklamálni, de a Steamről letöltött programokkal szemben a bizalom már meg van előlegezve, amit személy szerint nem értek, hiszen a gyakorlatban akárki, akármit publikálhat, mert nem ellenőrzi senki, legfeljebb utólag), de nem értem, miért nem futnak a játékok izoláltan, valami Docker-szerű környezetben.

És ugyanígy, miért nem az az alap, hogy az operációs rendszer csak egy réteg, ami közvetít a hardver és a konténerek között? Miért nem fut minden program a saját konténerében?

Nyilván van valami oka amellett, hogy ez így "lassabb" lenne, de a mai gépek már úgy is eszement módon fürgék, míg a kód egyre moslékabbá, terjedelmesebbé, törékenyebbé és lassabbá válik, így ideje lenne egy újratervezésnek.

Mit a rejtély magyarázata?

SZERKESZTÉS: Nem is annyira azt szeretném, hogy olyan OS-eket ajánljatok, ahol a konténer-szemlélettel kísérleteznek. Inkább azt szeretném megérteni, hogy miért nem ez a fő irány (általános használatra), illetve hogy lehet-e egyáltalán ez a fő irány valaha.

  • 2461 megtekintés

( arpad | 2024. 01. 10., sze – 09:21 )

Vannak ilyen disztribúciók, például a Flatcar Linux, a CoreOS utódja (asszem az is tovább ment valami hasonló néven). Ez egy alap minimális OS és minden workloadot containerben kell futtatni. Cloud környezetre van kihegyezve/szánva, nem desktop felhasználásra, gondolom neked inkább a desktop vonal lenne érdekes.

( vilmos.nagy | 2024. 01. 10., sze – 09:39 )

Snap? Flatpak? Ebbe az irányba megy a világ vagy 5-6 éve. 

( XYBeR | 2024. 01. 10., sze – 09:49 )

Windows-on a sandbox részben ilyesmi akar lenni.

Bárcsak az lenne! :) Eredetileg épp a Sandbox miatt vettem Win 11 Pro-t, de a gyakorlatban nem jó erre a célra, mivel nem sikerült megoldani, hogy lássa a videokártya drivert, így a játékaim nem tudnak elindulni "odabent". Persze meg tudom oldani másképp, de nem bántam volna egy ügyesebb homokozót.

Sandbox amúgy tud olyat, hogy valamennyire permanens? Sokszor kellene olyan, hogy egy pár hetes projekt keretében valami virtualizálva fusson, hogy a projekt végén egyben eldobhassam a picsába. Erre jelenleg WSL-t használok, de volt már, hogy kellett volna valami Windows-os szötty, amire overkill egy teljes Windows-t virtualizálni.

https://iotguru.cloud

A Mapped folders és a Logon command konfigurációjával lehet valamennyire szimulálni egy permanens-szerű környezetet, de 100%-ban nem lesz az, mert ugye pont az lenne a lényege. Illetve bonyolultabb esetekben kicsit hekkelős. Amit te írsz, arra akár jó is lehet rendesen felkonfolva. Ha jól látom a leírásból, akkor ilyen konfigból tetszőleges sokat tudsz csinálni, de hogy tudnak-e ezek egyszerre futni, az passz.

Szóval röviden: WSL-szerű dolog hiányzik nekem Windows-ból, amikor nincs konkrétan virtualizálva, közös kernel-en fut, viszont a user-space el van szeparálva és ha bármit feltelepítek, akkor azt el tudom dobni, nem szemetelem össze a meglévő (host) rendszert.

Nyilván ott a Hyper-V, használtam is már, csak az már macerás, hogy kvázi fel kell telepítenem, beállítani ezt-azt és-a-többi, míg WSL-ből annyi, hogy kreálok egy újat, használom, eldobom. Ez a Sandbox nagyon jó lenne, ha nem csak egy lenne belőle és meg tudná tartani adott ideig a feltelepített programokat, egyebeket.

https://iotguru.cloud

Értem, persze, nálam is felmerült már ez az igény, de végül elengedtem, mert ahhoz túl sok szívásnak tűnt, hogy nagyon belemenjek. :)

Amúgy, amit írsz, arra talán még a Windows Containers lehetne egy megoldás, csak annak meg a használata tűnik sokkal macerásabbnak a sandboxnál (bár bevallom, túl mélyen ebbe sem mentem még bele).

Szóval igazán jó és kényelmes megoldás szerintem sincs, de talán ma már valamennyire lehet közelíteni, csak azt kell kitalálni előtte, hogy miből vagy hajlandó engedni. :)

( dap | 2024. 01. 10., sze – 09:53 )

Szerkesztve: 2024. 01. 10., sze – 09:54

Van. Lásd Fedora Silverblue. De a sima Fedorán is telepíthető minden Flatpakból. Ez a jövő a Fedora szerint is.

Ezt a Silverblue-t már jó ideje nézegetem, de még nem sikerült rájönnöm, hogy miért akarnék váltani Fedora Workstation-ről. A manifestjükben megfogalmazott legtöbb gyakorlati célt a sima Workstation is hozza szerintem.

Ez a jövő a Fedora szerint is.

Azért ez messze nem az általános vélemény a Fedora csapatban:

What is the future of standard Workstation?

There is a possibility that the Silverblue will replace the regular Workstation. But there’s still a long way to go for Silverblue to provide the same functionality and user experience as the Workstation. In the meantime both desktop offerings will be delivered at the same time.

Csaba

( gelei v | 2024. 01. 10., sze – 09:57 )

Inkább azt szeretném megérteni, hogy miért nem ez a fő irány (általános használatra), illetve hogy lehet-e egyáltalán ez a fő irány valaha.

Szerintem ez a fo irany mar most is, csak kell ido, amig mainstreamme valik.

Nekem az a default, hogy eloszor a snap store-ban keresek valamit, es ha ott nincs akkor telepitem "rendesen". Sot, olyan is volt mar, hogy inkabb megcsinaltam magamnak a snapet.

( _ventura_ v | 2024. 01. 10., sze – 10:00 )

hogy ez így "lassabb" lenne, de a mai gépek már úgy is eszement módon fürgék

+

 míg a kód egyre moslékabbá, terjedelmesebbé, törékenyebbé és lassabbá válik,

Tehát tök jó, hogy vannak gyors gépek, akkor uccu neki  lassítsuk  le \o/  

Fedora 42, Thinkpad x280

Honnan nem fér hozzá ? A OS en futó másik alkalmazásból simán, sőt voltak bugok amiből kiderül, hogy elvileg a még jobban szeparált VM-ek is tudnak egymástól adatot szipkázin stb .

Ameddig van közös pont OS/CPU/RAM stb addig ezek bármikor fennállnak sajna

Fedora 42, Thinkpad x280

( eff | 2024. 01. 10., sze – 10:01 )

Szerintem azert nem ez a fo irany, mert ido es penz megoldani, hogy minden mindennnel szepen seamless modon egyuttmukodjon. A debugging nem tudom ilyen esetben mennyire valik problemassa (melyik containerben volt a hiba, miert, esetleg az egyikben mas verzioju program fut, mint amihez a masikban a kliens van, stb.)

Jelenleg nem tudom, hogy a GPU hozzaferes menyire transzparensen mukodik, illetve ha valami komolyabb #D cuccot akarsz kontenerbe pakolni, akkor hany GB-nyi libet/drivert kellene bepakolniod, es frissitened a konteneredet ha valami rajtad kivulallo dolog frissul (pl nvidia software/radeon software/intel software)

Attól függ van e külső függősége pl kubernetesben telepített rendszereknél amikor több tíz vagy száz csapat dolgozik valami megoldáson épp, na azt horror debuggolni. Ilyen 100+ konténeres csodára gondolj, alatta nem is érdekes már az élet.

Hétköznapi ember ezt nem fogja megugrani.

( azbest | 2024. 01. 10., sze – 10:02 )

Szerkesztve: 2024. 01. 10., sze – 10:05

Régebben volt balhé abból, hogy valamelyik játékot ms store-ból telepítve durván rosszabb fps-eket kaptak, mert a plusz rétegek miatt. Meg talán valami nem működött, talán variable refresh rate / fix 60fps cap vagy hasonló. Azóta lehet már megoldották.

Az oké, hogy olyan szolgáltatások boldogan futnak dockerben, amelyeknek csak hálózati forgalom igénye van a processzorhasználaton kívül, de gpu nem kell nekik.
Ahhoz, hogy teljesen szeparáltan futhassanak gpu intenzív alkalmazások, kellene támogatni a gpu virtualizációt is. Az enterprise kártyákon sok ezer vagy sok tízezer dollárért (nvidia esetén plusz licenszdíjért) lehet már ilyet csinálni. A desktopon még csak fokozatosan alakul és persze ezt a gpu gyártónak is kell engednie/támogatnia.

Persze egyszerűbb, nem teljesítményigényesebb játékokat lehet ma is megfelelően lehet butább fajta virtualizációval is használni. De ne passziászból vagy 3d sakkból indulj ki, hanem codból és hasonlókból.

Level1Linux csatornán most volt ilyen beszélgetés nemrég
https://www.youtube.com/watch?v=M2igdCDgA8o

( gazsiazasz | 2024. 01. 10., sze – 10:07 )

Légyszi ne akarjunk már mindenhová berakosgatni plusz teljesen felesleges erőforrás-égető rétegeket, csak azért, mert vannak balfaszok, akik nem képesek megoldani minimális egyszeri erőfeszítéssel járó dolgokat.

Valahogy el kell érni azt a fajta kompatibilitást, hogy egy update miatt ne reccsenjen meg az alkalmazás, mert épp eltört a libkutyafasza.

Ez az egyik legnagyobb oka annak, hogy nem készülnek Linuxra proprietary alkalmazások, illetve a régi nyílt programok se futnak megfelelően - iszonyatosan sok, és folyamatos karbantartást igényelnek. Egész egyszerűen drága dolog Linuxra fejleszteni. Ezen nagyon sokat segít a konténerezés.

Érdekes módon Windows-ra készülnek alkalmazások, használják az OS nyújtotta komponenseket, és egy Windowsupdate nem jelent eget rengető mennyiségű alkalmazásnál megborulást... Én inkább azt látom, hogy a (babzsák)fejlesztők kényelmesek, és lesz@rnak mindent és mindenkit, minden komponensből vagy a legutolsót, vagy a számukra szimpatikus 1024 évvel ezelőttit használják, aztán aki bújt, bújt, aki nem, annak meg lóhitty a hátsójába - aztán ha ezen a felhasználók háborognak, akkor csinálnak egybemindent "csomagot" - ez volt régen a statikusra buildelt bináris, ami manapság bloatcsomagolósan flatpack/snap formában él tovább...  Mintha a futyfurutty.jar hotná magával a számára szükséges JRE-t belecsomagolva, mert az úgy fajintos...

Igy volt, kb a Win 3.11 koraban, de ezt mar eleg regen megoldottak. Manaopsag egyreszt a WIndows alapveto DLL-eket ellenorzi a rendszer checksum alapjan, masreszt meg az alkalmazasok is a sajat konyvtarukba (sajnos az utobbi idoben egyre inkabb a %USERPROFILE% ala) telepulnek, tehat oda rakjak a sajat extra dll-jeiket.

( realkry | 2024. 01. 10., sze – 10:09 )

Pont akkora baromság mindent konténerbe erőltetni mint mereven elzárkózni a használatától minden körülmények között.

+1!

 

Én egy időben nagyon idegenkedtem tőle, aztán mindent beleeröltettem, most meg ott tartok, amit írtál. Bizonyos célokra hibátlan és sokkal jobb, mint bármi más megoldás, de van, ahol rengeteg plusz szívással jár. Utóbbira jó példa a mailserver. Beügyeskedtem konténerbe a Postfix, Dovecot, OpenDKIM, webmail komponenseket, majd ahogy sikerült életrekelteni, jött az igény a logrotate-re, syslog-ra és társaira.

Végül dobtam a konténert, szerintem levelező alá kifejezetten rossz ötlet. A Postfix önmagában chrootol, viszont a konténer miatt a Fail2ban és más külső komponensek összeigazítása nagyon melós. Ráadásul a Docker plusz réteg, ami egy restartnál, frissítésnél további gondot okozhat.

Most a gyakorlós levelezőm egy 2c/2G/60G gépen fut, kemény 2 eurós havidíjért, a backup MX egy 1/1/30-as 1 eurós gép lesz. Előbbin is karcos a konténer, ha szeretnék spam- és vírusvédelmet, de utóbbi meg aztán pláne olyan, hogy a konténer nagyon sokat elvesz. Mindkét gépen Debian 12 fut, cloud kernel-lel, stabilnak abszolút stabil, nem teszi be a kaput pl. egy docker update.

 

Ellenpélda a Node.JS, eszembe nem jutna ilyesmit konténeren kívül futtatni, nekem közvetlen Debian-on mindig voltak ilyen-olyan kínjai, már csak azért is, mert rengeteg főverzió, rengeteg package, nem is mindig konzisztens kódok.

TheAdam

A netcup-tól. Szokott lenni még ilyen-olyan providereknél (Ionos EU, sok noname) de a netcup régi nagy név, szép, tiszta IP tartományokkal, erős fraud detection-nel, így duplán erős az ár/érték arány.

 

( bazso | 2024. 01. 10., sze – 13:43 ) Permalink

Plusz memória, plusz tárhely... Ilyen kis gépnél sokat számít, ha határon van járatva.

 

( rascy | 2024. 01. 10., sze – 13:50 ) Permalink

Igen, ezek voltak az én problémáim is. Az OpenDKIM-nél nem is találtam módot, hogy stdout-ra logoljon, meg voltak itt anomáliák a Docker CE 24 körül, ami miatt úgy vagyok vele, hogy ilyen környezetbe idő, amíg visszanyeri a bizalmam.

 

Gondolom az f2b-vel a forward láncon tiltogatsz, vagy host módban van a konténer network? Bár, ha utóbbi, mármár okafogyottá válik a konténer.:D

 

Majd még küzdök vele én is, de először zöldfülűként elég kihívás a mailszervert működőre varázsolni és utána működésben is tartani hosszabb ideig, majd, ha ezt a részt már legalább kis rutinnal kezelem, újra nekiugrok a konténerizálásának. Bár lehet, akkor már kéne erősebb / nagyobb VPS, az ára miatt meg azt egyelőre nem eröltetném, gyakorlatilag 4 euró alatt megvan a primary és secondary szerver is, arra pedig, hogy játszadozzak, bőven baráti. Apró szépséghiba, hogy egy DC-ben, de más route-ön van a két gép, így azért nem olyan igazi az a failover, de megint csak az ár/érték arány mellett ez egy számomra vállalható kompromisszum.

TheAdam

OpenDKIM esetében egy már más által elkészített image-t használok:

- https://hub.docker.com/r/instrumentisto/opendkim
- https://github.com/instrumentisto/opendkim-docker-image

A megoldás a problémára röviden:
As far as OpenDKIM writes its logs only to syslog, the syslogd process runs inside container as second side-process and is supervised with s6 supervisor provided by s6-overlay project.
The syslogd process of this image is configured to write everything to /dev/stdout.

Fail2bannál pedig a "chain = DOCKER-USER" használata szükséges

In Docker 17.06 and higher through docker/libnetwork#1675, you can add rules to a new table called DOCKER-USER, and these rules will be loaded before any rules Docker creates automatically. This is useful to make iptables rules created by Fail2Ban persistent.

De van erre is már docker image :) 
https://github.com/crazy-max/docker-fail2ban
/ ránézésre egész jó, docker pulls 38M, csak időm nem volt még kipróbálni /

Az említett OpenDKIM image-t én is használtam, de egy mailszervernél számomra ez már a túlságosan tákolt kategória, annyira meg van erőszakolva az egész, hogy valahogy működjön, hogy mindig bennem a kisördög, egy frissítés nem fekteti-e le az egészet. Bár ez lehet kis személyes paranoia is, a gyakorlatban nem futok bele ilyesmibe. Az tény, nem láttam még sima Debian-on lévő mailszervert megborulni egy update-től.

 

Az f2b megoldásokat meg fogom nézni, köszi! Én eddig NfTables forward láncára csináltam tiltásokat az f2b-vel, de így ez hatékonyabbnak tűnik...

 

( h0lysh1t | 2024. 01. 10., sze – 19:33 ) Permalink

Ismerem, de én a tanulás miatt magam építem össze 0-ról az egész stack-et. Az ötletet köszi.

 

( kruska V | 2024. 01. 10., sze – 19:54 ) Permalink

Üzemeltettem ilyet egy haveromnál, nagyon egyben van, de az én célom most az, hogy magam legózzam össze, hogy ne csak működjön, de azt is értsem, miért. Köszi mindenesetre az ötletet.

TheAdam

Úgy általában egyetértek, de ezen fennakadtam: "a konténer nagyon sokat elvesz" - funkciót/hozzáférést vagy erőforrást? Az előbbi abszolút, nem mindenre jó a konténer, pont. A második viszont nem áll meg, mert kb nulla az overhead, annyira hogy rpi-n sem érzem meg.

A mailserver kapcsán szerintem hasonló utat jártunk be, bár én még nem értem a végére :)

Nekem jelenleg külön konténerben fut az OpenDKIM, Clamav és a Postfix + Dovecot.
A Dovecot-ot is külön akarom szedni, de nem volt még időm rá, meg nem is olyan egyszerű.
Jelenleg egy gondom van, hogy a Dovecot nem tud az stdout-ra loggolni (permission denied) és a bejövő levelek ez miatt nem érkeztek meg.
A logrotate, syslog helyett mindent az stdout -ra vezetek ki és a Docker logging beállítás alapján a log szerverre mennek tovább a bejegyzések.

A fail2ban kapcsán pedig jelenleg a log szerver (ugyanezen a gépen fut) készít egy külön logfile-t, amiben az összes alert (error, warning, fail, stb.) benne van és azt a host-on futó fail2ban látja, ami alapján tiltja az IP-ket.
Azt még ki kell találnom, hogy másik gépre hogyan küldöm vissza mit tiltson az ott futó fail2ban.

Ja és van hogy Docker restart esetén összekeveredik az iptables-ben a sorrend és hiába tiltja le a fail2ban az IP-t azt a Docker szabályai beengedik.
Ilyenkor teljesen kiütöm az iptables-t és mindent újra beállítok (írtam rá scriptet, szóval gyorsan megvan)

De ja, szívás ez így :)

Ha lesz időm, akkor azt fogom kipróbálni, hogy mindent egy VirtualBox alá teszek be Docker nélkül.
A Home Assistant egész jól elfut így headless módban.

A mailcow sem egy rossz választás.

 

CONTAINER ID   IMAGE                    COMMAND                  CREATED      STATUS                PORTS                                                                                                                                                                                                                               NAMES
acb0c43e7f43   mailcow/watchdog:2.00    "/bin/sh -c /watchdo…"   6 days ago   Up 6 days                                                                                                                                                                                                                                                 mailcowdockerized-watchdog-mailcow-1
207736ee2d3b   mailcow/acme:1.85        "/sbin/tini -g -- /s…"   6 days ago   Up 6 days                                                                                                                                                                                                                                                 mailcowdockerized-acme-mailcow-1
1a15853e5a7d   mailcow/netfilter:1.54   "/bin/sh -c /app/doc…"   6 days ago   Up 2 days                                                                                                                                                                                                                                                 mailcowdockerized-netfilter-mailcow-1
6243b6932140   mailcow/rspamd:1.94      "/docker-entrypoint.…"   6 days ago   Up 2 days                                                                                                                                                                                                                                                 mailcowdockerized-rspamd-mailcow-1
38541cb855fa   mcuadros/ofelia:latest   "/usr/bin/ofelia dae…"   6 days ago   Up 6 days                                                                                                                                                                                                                                                 mailcowdockerized-ofelia-mailcow-1
e1d227f38f44   mailcow/dovecot:1.26     "/docker-entrypoint.…"   6 days ago   Up 6 days             0.0.0.0:110->110/tcp, :::110->110/tcp, 0.0.0.0:143->143/tcp, :::143->143/tcp, 0.0.0.0:993->993/tcp, :::993->993/tcp, 0.0.0.0:995->995/tcp, :::995->995/tcp, 0.0.0.0:4190->4190/tcp, :::4190->4190/tcp, 127.0.0.1:19991->12345/tcp   mailcowdockerized-dovecot-mailcow-1
b5f6623ed589   nginx:mainline-alpine    "/docker-entrypoint.…"   6 days ago   Up 6 days             0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp                                                                                                                                                            mailcowdockerized-nginx-mailcow-1
8c811f490f93   mailcow/postfix:1.73     "/docker-entrypoint.…"   6 days ago   Up 6 days             0.0.0.0:25->25/tcp, :::25->25/tcp, 0.0.0.0:465->465/tcp, :::465->465/tcp, 0.0.0.0:587->587/tcp, :::587->587/tcp, 588/tcp                                                                                                            mailcowdockerized-postfix-mailcow-1
fef29c185881   mariadb:10.5             "docker-entrypoint.s…"   6 days ago   Up 6 days             127.0.0.1:13306->3306/tcp                                                                                                                                                                                                           mailcowdockerized-mysql-mailcow-1
ec03f968d821   mailcow/phpfpm:1.85      "/docker-entrypoint.…"   6 days ago   Up 6 days             9000/tcp                                                                                                                                                                                                                            mailcowdockerized-php-fpm-mailcow-1
437ff9b856f0   mailcow/clamd:1.63       "/sbin/tini -g -- /c…"   6 days ago   Up 6 days (healthy)   3310/tcp, 7357/tcp                                                                                                                                                                                                                  mailcowdockerized-clamd-mailcow-1
a83a8bdc4d1f   memcached:alpine         "docker-entrypoint.s…"   6 days ago   Up 6 days             11211/tcp                                                                                                                                                                                                                           mailcowdockerized-memcached-mailcow-1
5d5a03234824   mailcow/sogo:1.120       "/docker-entrypoint.…"   6 days ago   Up 6 days                                                                                                                                                                                                                                                 mailcowdockerized-sogo-mailcow-1
c0bea04f9abd   mailcow/solr:1.8.1       "docker-entrypoint.s…"   6 days ago   Up 6 days             127.0.0.1:18983->8983/tcp                                                                                                                                                                                                           mailcowdockerized-solr-mailcow-1
926afe50def4   mailcow/dockerapi:2.06   "/bin/sh /app/docker…"   6 days ago   Up 6 days                                                                                                                                                                                                                                                 mailcowdockerized-dockerapi-mailcow-1
b140801173c0   mailcow/unbound:1.18     "/docker-entrypoint.…"   6 days ago   Up 6 days (healthy)   53/tcp, 53/udp                                                                                                                                                                                                                      mailcowdockerized-unbound-mailcow-1
57a890cef2a0   mailcow/olefy:1.11       "python3 -u /app/ole…"   6 days ago   Up 6 days                                                                                                                                                                                                                                                 mailcowdockerized-olefy-mailcow-1
ab0420c6b217   redis:7-alpine           "docker-entrypoint.s…"   6 days ago   Up 6 days             127.0.0.1:7654->6379/tcp                                                                                                                                                                                                            mailcowdockerized-redis-mailcow-1

( trey | 2024. 01. 10., sze – 10:38 )

fejlesztőként praktikusnak találtam

Üzemeltetést kérdeztétek már?

trey @ gépház

( Sulc v | 2024. 01. 10., sze – 10:58 )

Amit szeretnél az olyan mintha mindent statikusan linkelnél a programodba. A konténer ehhez képest azt adja hogy nem írhat összevissza a filerendszerre + standard módszer az indításra.

( asch v | 2024. 01. 10., sze – 12:43 )

Valójában egy rakás izolácós réteg van, csak mind szar. 386 óta van az úgynevezett protected mode, ami a programok memóriaterületeit szétválasztja egymástól és az oprendszertől is. Tehát egy sima program eleve be van zárva egy sandboxba. (Vagy talán 286 óta is van? Azt nem ismerem, de mintha rémlene, hogy már abban is volt ilyen funkció, de az oprendszer ami tudta használni is, az nem terjedt el.)

Sajnos a sors iróniája, hogy az oprendszerek által adott API-k, amiken keresztül a programok kikukkantanak a saját homokozójukból tele vannak hibákkal, és emiatt ez a réteg nem bizonyult elégségesnek. A magánvéleményem az, hogy ezen a szinten szükséges volna egy modularizált rendszert építeni, ami a programok számára egy lekorlátozott API-t tudna adni. És annak a korlátozott API-nak lehetne egy részhalmaza, ami biztonságosnak tekinthető, és ami csak azt használja, azt lehetne futtatni bátran. Ilyesmit akart szerintem a Google Native Client csinálni: https://en.wikipedia.org/wiki/Google_Native_Client

A Docker, Flatpak, stb izolációk amennyire tudom nem is törekednek arra, hogy biztonságosak legyenek egy támadó ellen is, hanem csak arra, hogy a függőség kezelés független legyen alkalmazásonként, és valamennyire elválaszthatóak legyenek az erőforrások. Hasonló a wine is, amiből szintén tud egyszerre több működni, de az sem izolál biztonságosan.

A böngésző a JavaScriptet sandboxban futtatja, ezt eléggé biztonságosnak tartják manapság.

Vannak a virtuális gépes programnyelvek. Például a Java is ilyen. Ebből is elvileg lehet biztonságos sandboxot csinálni, de úgy tudom, hogy abban is folyton előjönnek biztonsági hibák, és nem nagyon szokás ilyesmire használni. Itt is a modularizálás segíthetne szerintem: kellene egy biztonságos minimum, amit még lehet könnyen auditálni. Ami meg annál több, ott felesleges a törekvés is.

Úgy tudom, hogy van olyan irány is, hogy a kernelben futtatható "virtuális gép" is készül. Ennek az a lényege, hogy a virtuális gép általi izoláció olcsó tud lenni, mert úgy tud biztonságosan kódot futtatni, hogy a hardver izolációt nem kell használni. Tehát a kernel kontextusban futhat user kód. Miért van szükség erre? A nagy teljesítményű IO esetén az alkalmazás-kernel határ átlépése bizonyul a legnagyobb költségnek. Ezt meg lehet spórolni, ha az alkalmazás egy része a kernel kontextusban fut. De a Kernel is biztonsági értelemben izolált a user processzektől Linux esetén ugye. Ezért csak egy bizonságosan korlátozott virtuális gépet lehet a Linux kontextusban futtatni az alkalmazás által.

Szerintem egyébként a teljesítmény miatt arra is volna igény, hogy ne legyen izoláció a kernel és az alkalmazások között se, vagy pedig könnyen tudjuk kernel kontextusban user kódot futtatni. Például beágyazott rendszerek, vagy pedig egyetlen szolgáltatásra dedikált szerverek esetén az izolációnak semmilyen haszna nincsen (azon kívül, hogy az alkalmazás crash-je esetén magát az oprendszert nem kell újraindítani), és ezekben az esetekben meg lehetne ezeket spórolni. Bizonyos terhelési profilok esetén meglepően sokat számít a user-kernel határ átlépegetésének a költsége.

( zrubi v | 2024. 01. 10., sze – 13:43 )

Szerkesztve: 2024. 01. 10., sze – 13:44

röviden:

mert a konténer nem csodaszer, és egyátalán nem véd minden ellen is.

 

bővebben:

- a legnagyobb 'limitáció', hogy kernel közös a host OS-sel. Ez biztonsági szempontból sem túl bíztató.

- aztán az ilyen konténerek menagelése, és frissen tartása is probléma - ha egyből nem is de később bitosan.

- teljesen szembemegy a csomagkezelős 'tradícióval'

- teljesen eltöri a csak megbízható forrásból telepítés elveit is.

- windows-on az egész értelmezhetetlen, nincs valós konténer megoldás.

 

szerintem.

zrubi.hu

- teljesen eltöri a csak megbízható forrásból telepítés elveit is.

Miért is? Miben különbözik egy container image egy rpm/deb-től ilyen értelemben?

- teljesen szembemegy a csomagkezelős 'tradícióval'

Miért is? Miben különbözik egy csomag meg egy container image a csomagkezelős 'tradíció' szempontjából?

- aztán az ilyen konténerek menagelése, és frissen tartása is probléma - ha egyből nem is de később bitosan.

Miért is? Minden tartható frissen, csak tooling kérdése (lásd flatpak).

- windows-on az egész értelmezhetetlen, nincs valós konténer megoldás.

Mit értesz valós meg nem valós konténer megoldás alatt?

Miért is? Miben különbözik egy container image egy rpm/deb-től ilyen értelemben?

a hivatalos apt repok signelve vannak, ha ott megvaltozik a csomag akkor torik az alairas. egy nginx imagerol hogy mondod meg hogy azt valoban az nginx rakta fel a hubra vagy nem egy hekker cserelte ki az imaget valami okositott verziora?

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A Docker image-k is alá vannak írva.

https://docs.docker.com/engine/security/trust/#about-docker-content-tru…

A példádban említett nginx image esetén is ott az aláírás, ellenőrizhető:

persicsb@artemis:/$ docker trust inspect --pretty nginx:latest

Signatures for nginx:latest

SIGNED TAG   DIGEST                                                             SIGNERS
latest       2bdc49f2f8ae8d8dc50ed00f2ee56d00385c6f8bc8a8b320d0a294d9e3b49026   (Repo Admin)

Administrative keys for nginx:latest

  Repository Key:    ec92eb8e988506253f8590cb924b6becdbb0520f2fb430257d8879e2d3bed2cc
  Root Key:    d2f02ea35ebffce87d31673efbff44c199b1af0be042989d4655a176e8aad40d

Ha a hacker hozzáfér a docker repo admin kulcsához, annak gratulálol.

Ez nem mindig garancia arra hogy egy contributor ne tudna beletenni kártékony kódot. Nem a kulccsal fog szarakodni hanem hozzádob 100 soros commitot, amiből pár sor kártékony.
Code reviewerek átnézik, elnéznek fölötte és máris egy signes cucc van amiben problémás kód van.

De ez ellen az rpm/apt aláírás ugyanúgy nem véd. Ha a forrásban van pár kártékony kód, az ugyanúgy bekerül a csomagba. Ezért kérdezem: miben más lényegesen a hagyományos linuxos csomagkezelés megbízhatóság szempontjából, mint a konténer image-k?

Vagy szerinted a Debian által buildelt xyz random csomag nem a Githubon fellelhető forrásból épül? Lásd a readme-t itt: https://github.com/Debian

Debian packages, maintains and distributes many projects developed using GitHub. This account was created to facilitate push/pull interactions with the upstream developers of such projects. If you maintain a package whose upstream developers use GitHub, please feel free to join this group and mirror such project here.

Sot: az image build nem feltetlen resze a CI-nek.

Hanem hebe-hoba az egyik contributor fordit egyet sajat gepen (itt ugye olyan forrasbol tud, amelyiket csak akar), aztan docker push, es hopp, aki :latest -et hasznal, mar futtatja is.

Foleg kisebb projekteknel siman igy megy a release, szoval csak ovatosan azzal a docker-rel is.

Miért is? Miben különbözik egy container image egy rpm/deb-től ilyen értelemben?

Legfőképpen abban, hogy egy disztribúciónak van (egy vagy több) saját repója. Mondjuk te megbízol a RedHat-ban, (mindegy miért) akkor az általuk karbantartott repóból csak olyan dolgok jönnek, amire ez a megbíhatóság (szerződés, trust, hit, support, vagy akármi miatt) érvényes.

persze gyakorlatban tlepíthetsz  más repókból is, de onnantól ugyan úgy el kell fogadnod azt a repót is ugyan olyan szintű megbízhatóságúnak, mint a gyáriakat.

Sőt, telepthetsz random letötött .rpm-eket is, de onnantól megint felrúgtad ezt a szabályt - vagy megbízol abban az egy .rpm-ben (mert pl a saját fejlesztőid készítették)

 

A konténereknél ez teljes mértékben követhettlen, nincs egy közös repó, hanem minden 'fejlesztő józsi' publikálhatja a saját vackait.... amit hiába ír alá, ha közben a benne lévő random forrásokból jövő dolgokra nincs is ráhatása. A 'trust chain' követhetetlen. - kivéve persze, ha saját magadnak (és/vagy cégen belül) készíted a konténereket...

 

a gyakorlatban ráadásul ugyan az a 'fejlesztő jóska' biztosan nem csinál mindenhez is konténert amire neked szükséged lenne, tehát ~minden konténered különböző forrásból jön -> innentől pedíg a megbízható forrás értelmezhetetlen.

 

szerintem.

zrubi.hu

Miért is? Miben különbözik egy csomag meg egy container image a csomagkezelős 'tradíció' szempontjából?

a csomagkezelő lényege, hogy van egy OS szintű adatbázisod arról, hogy pontosan mileny csomagok vannak telepítve. Innentől könnyű ellenőrizni, hogy frissült-e valami, ha igen upgradelni az adott csomagokat.

 

- Egy konténer belsejében hogyan látod hogy elavult/sérülékeny lib van használva?

-mindezt OS szinten hogyan kezeled? Még ha van is rá tooling, akkor is innentől már annyi külön csomag adatbázisod lesz ahány konténered.

 

szerintem.

zrubi.hu

Mit értesz valós meg nem valós konténer megoldás alatt?

OK, ez valóban nem túl konkrét :)

Ez inkább csak előítélet: eddig nem győzött meg a windows, hogy képes bármilyen hatékony szeparációt elérni OS-en belül.

És mivel ez zárt forrású, várhatón így is marad. Persze hinni lehet benne :)

 

ezzel szemben Linux vonalom már a ~kezdetektől volt 'chtoot jail', és ezt támogó kernel hardening - tehát már bizonyított :) - és a forrása sem titkos  -> így számomra megbízhatóbb, hihetőbb, minden ismert limitációjával együtt.

 

szerintem.

zrubi.hu

( Raynes v | 2024. 01. 10., sze – 19:18 )

Ez sose lesz főbb csapásirány. Okok
1) legtöbb usernek overkill
2) ahogy írták, nem csodaszer, nem véd minden ellen
3) azért mégis csak erőforrás-növelő tényező. Igen, a mai gépek fürgék, de nincs mindeim looking for moving tonkinek mai gépe, meg ezen kívül vannak speciális, beágyazott meg ipari felhasználások, amikor nem szarakodnak konténerekkel, virtualizációval, egyéb paranoid úri huncutságokkal.

Egyébként attól, hogy nem fő csapásvonal, ma már több minden használja, mint pár éve. Pl. immutable disztrók nem egészen konténerek, de mégis csak valamennyire konténerizált univerzális csomagformátumokkal dolgoznak a sajátosságaik miatt (tipikusan Flatpak). Vagy a Qubes OS, az viszont virtualizál. Nem lehetetlen, hogy ez még jó pár év múlva ennél is népszerűbb lesz, de fő csapásirány az majdnem biztosan garantálhatóan soha. Bár ki tudja, lehet csak én vagyok szűk látókörű, a Windows 11 pl. már ma is virtualizálva futtat minden alrendszerét, szóval várjuk ki. Az ilyen túl vad ötletek állandóan jönnek, hogy az egész rendszer konténerizálva, virtualizálva, meg legyen az egész webes (lásd ChromeOS), stb..

Igazából nem is kell ehhez fő csapásirány, ha ilyet szeretnél használni, akkor igazából a fentebb említett disztrókon kívül is nyugodtan használhatsz akármelyik n+1. disztrón distroboxot, amivel azt konténerizálsz magadnak a saját rendszeren, amit csak akarsz, senki nem fog le ebben. Windows az nem erre van építve, az az egyszeri átlag usernek meg öltönyös-nyakkendős üzletembernek, azok örülnek, ha az alap feladatokat meg tudják csinálni a gépen, egy kattintásos megoldással, nem nagyon az a réteg, akit megörvendeztetnél a konténermániával, meg mindenféle absztrakcióval.

Én magam nem vagyok nagy híve. Szerintem érdemes a szoftverek minimális komplexitási fokon tartani, a fejlesztést megkönnyíti, olcsóbbá teszi, a debugolás is könnyebb, meg nem kell a fenntarthatóság miatt mindig hardvert cserélni. De a konténer azért néha hasznos, pont az, amit írsz, pl. ha egy szoftvernek egyszerre több verzióját is használni akarod a rendszeren, tehát nem haszontalan, csak túlfetisizálni nem kéne. Megvan a használati köre, akinek erre van szüksége, az tudja használni, mint írtam, ehhez meg nem kell az OS-nek magának speciálisan konténerekre kigyúrva lennie.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”