Ich mach Pause von Kodi

Was? Warum?

Volumes sind ein gängiges Thema in Docker und nicht weg zu denken.

Ich wollte mit meinem Beispiel nur sagen, dass

• wenn ich nicht root bin
• Docker installiert ist
• ich als non-root User einen Container starten kann, der dann innerhalb des Containers root ist (ist bei fast allen Containern so)

ich mir ganz easy einfach ALLES in den Container mounten kann. Unter anderem auch "/etc". Und dann ist es mir schon egal ob ich auf dem Host root bin oder nicht. Denn dann hole ich mir root über den Docker, trage mich in die sudoers ein, ändere Passworte und was weiß ich noch alles.

@tavoc es geht mir dabei wie ich ein System angreifen kann und nicht was "Best Practice" wäre

das klappt nur, wenn du den Container als root ausführst oder ID/GRoup 0 ist

aber ich glaube wir schweifen auch hier ab

Zitat von tavoc

das klappt nur, wenn du den Container als root ausführst oder ID/GRoup 0 ist

Was du nicht sagst Das habe ich ja gesagt. Steht ja oben so

Und sehr sehr viele Container haben intern root. Da reicht es, wenn ich mir einen dusseligen Apache-Container (httpd heißt der) installiere. Was ich mir dafür ziehe ist ja erstmal egal. Irgendeinen Container finde ich schon. Zur Not ein Ubuntu und da kann ich dann mit sudo arbeiten.

Naja. Eine idee von containern ist ja, das man da drin alte Software verewigt, auf die man angewiesen ist, aber die nicht weiterentwickelt wird. Und bei der man deswegen davon ausgehen kann, das die sicherheitsluecken haben wird.

Aka: man muss da vor allem gucken, das ein root im container moeglichst kein einfalltor fuer den rest des systems darstellt. Das ist natuerlich nicht einfach. weiss z.b. gar nicht, ob man dateisysteme, die man in einen container reinmounted z.b. einfach fuer rootzugang sperrt. ALso so wie man es bei nfs machen kann. Klar, man koennte im container via nfs mounten, aber wer macht das. Und netztechnisch sollte dann verkehr von solchen container auch eher noch mal durch eine firewall durchgehen, statt als interner verkehr zu gelten.

Und natuerlich snd die regeln anders, wenn man der sicherheit so einer container-app genau so trauen kann wie die einer die selbst von debian/ubuntu gevettet wurde...

Etc. pp. Ist schon sinnvolles tool so container, aber sicherheitstechnisch eine neue Herausforderung.

Das Problem ist überschaubar. Was DaVu meint ist dass wenn der Docker Daemon als root läuft, mal beliebige Pfade des Dateisystems da rein mounten kann und eben dort im Container lesen und schreiben kann.

Normalerweise kann nur root überhaupt Container starten außer man erlaubt das explizit auch anderen Benutzern. Man auch den Docker Daemon rootless benutzen mit ein paar Einschränkungen. So oder so braucht ein Angreifer erstmal Zugriff auf den Host, um den von DaVu beschriebenen Angriff auszuführen.

Stimmt. Ich hatte jetzt auch nicht probiert, die von @DaVu beschriebenen Angriffe zu kommentieren, sondern die, die mir sofort offensichtlich waren: als Root in teilen des Host dateisystems rumpfuschen zu koennen weil man beliebige ID (root oder anders) haben kann, und beliebige Pakete senden/empfangen zu koennen, weil man rootprozesse starten kann.

Aber wie gesagt. Vielleicht gibt es ja auch geschuetztere container wo gar kein root moeglich ist. kenne mich da leider nicht aus bei den ganzen privilege controls die es da fuer containern gibt. Wuerde die sache natuerlich sehr vereinfachen.

Docker kann man definitiv "härten". Oftmals verbunden mit eigenen Docker Images, die man sich selbst baut. Das, was man von Docker Hub bekommt ist meist für die breite Masse gemacht,

Und grundlegend ist es auch nicht soooo schädlich einen Docker als root laufen zu haben. Viele nutzen diese Services rein intern im eigenen Netz. Man kann halt, wie bei so vielem, die Sache aber auch ausnutzen. Man muss halt nur wissen wie.

Wenn ein Container mir mal kein root gibt, dann baue ich ihn halt so um bis ihn halt so habe wie ich ihn brauche.
Das ist noch nicht mal schwer. Und ich bezeichne mich bei weitem nicht als Docker-Guru. Im Endeffekt sind die meisten Docker Container ein stupides Linux. Und wenn ich darin root bin und mir von "außen" Dateien rein hole (via Volume) dann haben die Dateien "root:root" im Container und ich habe die I'D "0"
Das üble daran ist....Das hinterlässt keine Spuren. Ich kann die History löschen, Logs manipulieren....etc. pp. Als root kann ich alles machen.

Man kann Docker aber auch so einstellen, dass ich einen Container nur als root starten kann. Den Container kann ich so umbauen, dass er intern kein root hat. Das ist oftmals etwas trickreicher, da die Anwendung im Container dafür ausgelegt wurde unter root zu laufen. Bei einem Apache Container muss ich dann Dateiberechtigungen anpassen, damit der Container startet. Das ist etwas aufwändiger als einen non-root Docker für root umzuschreiben. Aber es geht und man kann auch das sicher gestalten.

Zitat von jkdask

Normalerweise kann nur root überhaupt Container starten außer man erlaubt das explizit auch anderen Benutzern. Man auch den Docker Daemon rootless benutzen mit ein paar Einschränkungen. So oder so braucht ein Angreifer erstmal Zugriff auf den Host, um den von DaVu beschriebenen Angriff auszuführen.

Genau so isses.

Die offizielle Anleitung zur Installation von Docker unter Linux sieht das aber schon so vor, dass ich Docker als non-root User starten kann. Der Daemon als solches läuft natürlich unter Root. Und ja...ohne Zugriff auf den Host geht da natürlich nichts. Aber spinnen wir mal weiter....eine Kodi Instanz, die nicht unter root läuft....ein dubioses Add-on, welches mir eine reverse shell eröffnet und dann läuft vielleicht auch noch docker auf dem System wo ich einen Container als non-root starten kann. Da bin ich schneller root als manche "Blaubärkuchen" sagen können

Wie @tavoc aber schon ganz richtig sagte....wir schweifen hier wirklich ein wenig ab. Es macht nur Spaß darüber zu schreiben und das Wissen zu teilen. Vielleicht hilft es ja dem ein oder anderen.

Zitat von te36

Naja. Eine idee von containern ist ja, das man da drin alte Software verewigt, auf die man angewiesen ist, aber die nicht weiterentwickelt wird. Und bei der man deswegen davon ausgehen kann, das die sicherheitsluecken haben wird

Das ist vielleicht wirklich nur "eine" Idee. DIE IDEE ist das definitiv nicht. Ganz im Gegenteil. In Zeiten von Kubernetes ist das völlige Gegenteil der Fall. Das schöne an Containern ist, dass ich nicht alle Abhängigkeiten auf dem Host-System installieren muss um eine einzelne Anwendung zu betreiben. Ich muss mein System nicht mit Java zu müllen, nur weil ich es vielleicht für eine Anwendung brauche, die ich auch in nem Docker laufen lassen kann. Da habe ich die Abhängigkeiten innerhalb des Containers und auch nur dort. Und im Verbund mit Kubernetes läuft das ganze dann auch noch verdammt hoch verfügbar.

Das einzige, was sich der Container mit dem Host teilt, sind Netzwerk, CPU, RAM und den Kernel. Viel mehr aber auch nicht. Alles andere ist ziemlich autark. Natürlich kann ich auch alte Software in einem Container installieren. Das ist aber nicht der Grundgedanke.

Ich betreibe an der Arbeit in dem Team, in dem ich tätig bin unsere komplette Produktion inklusive des Monitorings, des Loggins und Alertings komplett in Containern. Wenn ich da meinem Kunden mit "wir haben da mal alte abgehangene Software installiert" komme, dann bin ich meinen Job los . Latest und greatest muss es auch nicht sein....aber wenigstens "stable" und nicht "eol".

@DaVu nur wenn du user explizit der Gruppe docker hinzufügst. Ansonsten können normale User keine Container starten. Und es gibt eigentlich keinen Grund, warum man irgendwas aus etc vom host in den Container mounten würde.

Mal so als Google-Recherche für euch: Es gibt von den Fedora-Leuten eine Docker-Alternative namens Podman, die ohne zentralen Daemon auskommt und im Grunde mit User-Rechten wie eine "normale" App bestückt werden kann!

Werde mich im Rahmen meines neuen Media Storage damit tiefer beschäftigen.

Zum Reinschnuppern kann man sich übrigens "Podman Desktop" für Windows runterladen. Ist deren Pendant zum Docker Desktop!

Podman ist quasi ein Drop In Replacement für Docker und hat das gleiche CLI und unterstützt auch Composer. Ich kann es momentan noch nicht verwenden weil eine App noch Docker erfordert aber würde es sonst auch nutzen.

LXC ist auch eine Alternative mit der man unpreviligierte Container nutzen kann ist aber kein Drop In Replacement wie Podman

Das gibt es nicht nur für Fedora. Ist auch schon ziemlich lange aufm Markt. Ich nutze Fedora und auch immer noch Docker. Läuft tadellos.

Verwende aber auch Podman an der Arbeit in unserer Build- und Deploy-Pipeline. Das läuft sogar stabiler als Docker. Lustiger Weise bauen wir somit mit Podman Docker Images ;).

Grundlegend ist es pupsegal was für ein Overlay darüber läuft. Unter der Haube ist es ohnehin Containerd.

@jkdask

Zu sagen, dass es keinen Grund dafür gibt, ist doch ziemlich weit her geholt. Es kommt immer auf den Anwendungsfall an. Ein Dnytrace Container zum Mutli-Cloud Monitoring mounted sich den kompletten "/etc" als zusätzlichen Pfad in seinen Container. Das ist ein ganz normales Verhalten. Sonst könnte der Container weder seinen Host noch die auf dem Host laufenden Container monitoren.

Ich gebe zu....ein ziemlich mächtiger Container und weit weg von "üblich" aber so funktioniert er nun mal.

Von daher....Es kommt immer drauf an, was ich machen möchte

@DaVu: Habe auch nie gesagt, dass das nur für Fedora ist ... es wurde von den Fedora-Leuten entwickelt!

Kann es auch sehr einfach über die Repos von Debian installieren ...

Jo, "die" idee von Docker, die mich am meisten gequaelt hat war ja genau das mitfuehren der ganzen historie, wodurch das immer Blaehware wurde. Habe dann gerne auch einfach ein Chroot selbst gebastelt als wirklich lightweight Loesung. Mir ist schon klar, wie das in kubernetes Umgebungen verwendet wird, abre ich bin da eher jemand, der sich fuer die moeglichst leichtgewichtigen app-container interessiert. Und so wie sich docker da seinen inhalt mounted finde ich das auch gruselig. Wie gesagt, chroot erreicht fuer isolation vom OS dasselbe einfacher. Aber natuerlich wurden ins linux wegen dem ganzen container-hype sehr viele schoene neue features eingebaut um jails fuer container zu basteln (wenn ich das so nennen kann). Bloss das ich mich durch die in der Tiefe noch nicht durchgelesen habe.

Mein erster docker war halt mal einfach den squeezeboxserver zu containern, weil ich gentoo hatte, und die squeezebox community hatte es mehr als ein jahr lang nicht geschaft den server fuer glaube ich perl 5.16 (oder 18) zum laufen zu bringen, und gentoo mochte kein aelteres perl mehr, also inkompatible app mit dem OS, also container. Und so'ne app muss natuerlich zugriff auf alle musike haben, also mounten. und dann mag ich nicht, wenn die config-files tief in einem container stecken, die mag ich wie normal in /etc, war also auch schwierig. Und am Ende war das Teil 800 MByte gross. Und kleiner waere nur gegangen mit viel arbeit, sich einen kleinen basis linux-container zu scuhen in den ich ein perl mit "allem" installieren koennte.

@DaVu wofür braucht der konkret dafür etc? Welche Dateien daraus für welchen Zweck?

Anscheinend muss sogar nicht nur etc sondern der komplette Root gemountet werden für OneAgent. Ist schon eher ungewöhnlich.

Wer hat denn jetzt die Buch-Rechte an der Diskussion.
Ihr @DaVu und @te36 Ihr glaubt doch nicht wirklich das ich das alles hier lese.
Ihr habt es mit einander das passt in zwei Bücher.

Vertragt Euch oder ich schicke den Markus zum @te36

Andere Frage, sehen wir uns dieses Jahr mal?

Ich hab' noch ein paar Fotos vom Markus, die können ja dann ins Buch mit rein...

@rolappes darf hier jeder gern an der Diskussion Teil nehmen.

@te36 und ich müssen uns nicht vertragen weil wir uns gar nicht streiten. Ich verstehe das Problem gar nicht.

Dürfen wir hier nicht mal offen über Security Themen sprechen. Ich finde es ein extrem interessantes Thema und spreche gern darüber. Und offensichtlich erzeugt es einige Aha-Effekte. Auch bei mir.

@jkdask stimmt. Das komplette root wird gemountet. Was mit Dynatrace geht ist schon richtig mächtig. Das geht runter bis auf Code analyse während der Laufzeit.

Warum es nicht nur gezielt die eine oder andere Datei sein kann, musst du die Dynatrace Entwickler fragen. Im Endeffekt liest das Teil jeden auch nur verfügbaren Socket aus. Das Ding sagt dir sogar wie lange es gedauert hat bis die Website bei einem User in der Mongolei vollständig für ihn sichtbar war. Das Ding ist der Knaller wenn es um Analyse geht. Als "nicht Entwickler" verstehe ich oftmals nur Bahnhof. Unsere Entwickler sind aber sehr dankbar, wenn es mal Performance-Einbußen gibt.

Zitat von Ponyriemen

Ports von TVH (9981/82) auf andere Ports von extern verfügbar gemacht. Wobei wohl 9981 das Problem gewesen sein kann iVm dem Standard User. Vermute ich. Keine Ahnung.

War Dir nicht bekannt, das man mit der Fritzbox WireGuard nutzen kann, oder unterstützt das Deine FB nicht?