Sicherheitstipps für Container Manager

[Meck]

Hallo zusammen,

gibt es Sicherheitstipps oder Empfehlungen für den Synology Container Manager?
Was kann ich tun um das Ausbrechen aus einem Container zu verhindern / erschweren?

Bei Synology auf der Website habe ich nichts gefunden.

Danke schon mal im Voraus.

 

[Uwe96]

Was soll da denn ausbrechen?

 

[alexhell]

Du solltest auf jeden Fall die Container nicht als root laufen lassen. Aber ein Ausbruch vom Container zum Host ist extrem selten. Aber natürlich, unmöglich ist das nicht. Ansonsten gibt es da nicht so viel was du machen kannst. Wie gesagt nicht als root laufen lassen und die Images sich angucken bevor man die blind verwendet.

 

[Meck]

Du solltest auf jeden Fall die Container nicht als root laufen lassen. Aber ein Ausbruch vom Container zum Host ist extrem selten. Aber natürlich, unmöglich ist das nicht. Ansonsten gibt es da nicht so viel was du machen kannst. Wie gesagt nicht als root laufen lassen und die Images sich angucken bevor man die blind verwendet.

Meinst du damit die Funktion "Den Container als privilegierten Container ausführen."?

 

[alexhell]

Nee, aber das sollte man auch nicht machen, außer es hat einen ganz bestimmten Grund und man weiß halt wieso.
Du kannst angeben unter welchem User der Container laufen soll. Diese sollte nie der root sein.

Edit: Und Docker Befehle sollte man nicht ohne sudo Ausführen. Wer neue Container erstellen kann, kann mit dem System machen was er will.....

 

[Meck]

Danke für die Info - Wie mache ich das innerhalb vom Container Manager oder geht das nur über die CLI?

 

[alexhell]

Keine Ahnung, ich nutze den Container Manager nicht. Der macht alles nur unnötig kompliziert und das ewige zusammen geklickt nervt mich eher.

 

[haydibe]

Meinst du damit die Funktion "Den Container als privilegierten Container ausführen."?

Ein solcher Container ist so schwach isoliert, dass man hier den Ausbruch Richtung Host nicht verhindern kann.

Man sollte NIE einen priviligierten Container verwenden. Stattdessen sollte man nur explizit benötigte Capabilites einzeln hinzufügen für den Container. Diese sollte dann auch in der Dockerhub-Beschreibung stehen.

Weitere Sicherheitsmaßnahmen, die nichts mit der Container Manager Oberfläche zu tun haben:
- Webanwendungen sollten nicht als Root-User laufen. Ein Container, der zwr als root startet, aber die Webanwendung als nicht root starte ist dagegen okay.
- Idealerweise sollte nicht jeder Container, der als nicht privilegierter Benutzer ausgeführt wird, dieselbe UID haben, und diese sollte idealerweise nicht die UID von einem Benutzer sein, der in der Admistratoren Gruppe ist.

Weitere Hinweise für den sicheren Betrieb vom Containern findet man hier in meinem Post https://www.synoforum.com/threads/securing-docker-containers.13075/post-65135

 

[Meck]

Danke @haydibe

Wenn ich das nun alles richtig verstand habe, dann müsste ich einen weiteren User in der Synology anlegen und diesem User nur Zugriff auf den Freigegebenen Ordner "Docker" (Lesen/Schreiben) geben.

Auf der Synology CLI starte ich den Container dann mit folgendem Befehl (z. B. Uptime Kuma)

sudo docker run -d \
--name uptime-kuma \
-v /volume/docker/uptime-kuma:/app/data \
-p 3001:3001 \
--user [Neuer Synology-User]:users \
louislam/uptime-kuma

... dann würde der Container unter dem neuen Synology-User ausgeführt und hätte somit auch keinen Zugriff auf die anderen Ordner / Shares / Volumes auf der Synology?

​

 

[Monacum]

Nein, mit sudo läuft der erstmal als root, du müsstest ihm noch im Kommando einen Befehl für die zu verwendende GID und UID mitgeben. Und was @haydibe noch schreibt, die von einem User, der keine Adminrechte hat, sondern dein User, der nur auf Docker zugreifen kann.

 

[alexhell]

Das wäre fahrlässig @Monacum. Der Docker daemon läuft als root. Wenn du einem nicht Admin User ohne sudo erlaubst Docker Befehle auszuführen, dann kann er durch Docker alles machen was er will. Außer der daemon läuft als root-less. Aber das ist bei Synology ja nicht der Fall.

@Meck ja super kannst du es machen

 

[Monacum]

Ok, dann bitte nochmal in einem Post, auch für mich, das korrekte Setup:

• Mit welchem Benutzer führt man am sichersten den sudo docker compose…-Befehl aus? sudo geht doch nur mit Admin-Usern oder bin ich da auf dem falschen Dampfer?
• Was bewirkt dann das Setzen von GID/UID? Habe das tatsächlich so verstanden, dass der Container dann mit den entsprechenden Benutzerrechten arbeitet.

 

[alexhell]

Es gibt einen Unterschied zwischen einen Container starten und in welchem Kontext der Container läuft. Das starten sollte ein Admin User machen. Also mit sudo. Wer Zugriff auf den Docker Daemon (außer bei rootless) hat automatisch root Rechte.

Mit welchem Benutzer führt man am sichersten den sudo docker compose…-Befehl aus? sudo geht doch nur mit Admin-Usern oder bin ich da auf dem falschen Dampfer?

Das machst du ganz normal mit deinem User und sudo. Auf der Synology wäre das dann halt dein Admin User.

Was bewirkt dann das Setzen von GID/UID? Habe das tatsächlich so verstanden, dass der Container dann mit den entsprechenden Benutzerrechten arbeitet.

Genau das setzen der GID/GUID sorgt dafür als welcher User der Container läuft. Das hat @Meck in seinem docker run Befehl ja auch genau so gesetzt. Es gibt Container die nehmen eine GID/GUID als Environment Variable an. Du kannst aber auch einfach den User in der Compose/per docker run Befehl festsetzen. Dann läuft dieser Container mit den Rechten vom angegeben User.
Es gibt halt aber auch Images die funktionieren dann einfach nicht, weil sie nie den User wechseln und meinen Root Rechte zu brauchen. Dann sollte man diese Image halt meiden.

 

[Meck]

Hallo zusammen,

ich muss meinen Post korrigieren, da mein run-Befehl so nicht funktioniert.
Ich erhalte beim Ausführen eine Fehlermeldung, dass der Container den User, der mit der Option „--user“ mitgegeben wird, nicht finden kann.

Der Grund für die Fehlermeldung ist, dass mit der Option —user der erste Prozess innerhalb des Containers nicht mit dem User root startet sondern mit dem angegeben User unter —user.

Hier die offizielle Docker Beschreibung:

User
The default user within a container is root (uid = 0). You can set a default user to run the first process with the Dockerfile USER instruction. When starting a container, you can override the USER instruction by passing the -u option.

Quelle: https://docs.docker.com/engine/reference/run/#user




Ich glaube müsste bei meinem Beispiel anderes vorgehen:

1. Einen neuen User im DSM anlegen und in die Gruppe „docker“ hinzufügen.

2. Im DSM dem neuen User nur Zugriff (RW) auf den Ordner „docker“ geben und alle anderen Ordner im DSM sperren

3. Mit dem neuen User bei der DSM CLI anmelden und den Befehl ausführen:

docker run -d \--name uptime-kuma \
-v /volume/docker/uptime-kuma:/app/data \
-p 3001:3001 \
louislam/uptime-kuma

Nun sollte der Container unter dem neuen User laufen.

So in der Theorie Ob es funktioniert oder ob ich einen Denkfehler habe muss ich heute Abend mal testen …

 

[alexhell]

Nein......
1. Standardmässig (bei Synology) können sich nur Admins per SSH verbinden.
2. Dein User der kein Admin ist, hat Zugriff auf den Docker Daemon => root Rechte. Das habe ich doch schon häufiger geschrieben. Nur User die auch root Rechte haben, dürfen auf den Docker Daemon zugreifen.

 

[haydibe]

Nun sollte der Container unter dem neuen User laufen.

Das ist absolut falsch!

Der Docker Demon wird immer mit dem root User ausgeführt - und damit auch alles was der Docker Demon tut. Jeder der berechtigt ist auf docker.sock zuzugreifen, kann alles(!) mit Docker tun.

Die Docker cli (Container Manager, Portainer, und co) sind Client Anwendungen, die über den docker.sock Anweisungen an den Docker Demon senden, der diese dann umsetzt. Der Docker Demon bekommt überhaupt nicht mit, welcher Benutzer die Docker CLI verwendet - ist ihm auch egal, da alles als root läuft.

Unabhängig davon kann man einen Container als unprivilegierten User starten, bspw. durch `--user $(id -u meintoolleradmin)` oder `--user 1030`.

 

[Meck]

Danke @alexhell und @haydibe für Eure Erklärungen und Support!

Mit der Option --user schaffe ich es nicht meinen Test-Container zu starten. Für das Erstellen vom Uptime-Kuma Container sind root-Rechte notwendig, da beim Erstellen der chown-Befehl ausgeführt wird und dies funktioniert nicht mit dem normalen User.
Fehlermeldung:

chown: changing ownership of '/app/data/kuma.db': Operation not permitted
chown: changing ownership of '/app/data/docker-tls': Operation not permitted
chown: changing ownership of '/app/data/screenshots': Operation not permitted
chown: changing ownership of '/app/data/upload': Operation not permitted

Lösung:
Ich muss es mit root-Rechten laufen lassen oder ich lasse einfach keine Container auf meiner Synology laufen.

 

[alexhell]

Was ist denn wenn die Ordner schon den richtigen User haben? Kannst es doch vorher anlegen und selber den User festlegen

 

[Meck]

Was ist denn wenn die Ordner schon den richtigen User haben? Kannst es doch vorher anlegen und selber den User festlegen

Nop, geht leider nicht.

Ich habe noch in der Doku von Uptime Kuma etwas gefunden. Wenn man die Umgebungsvariabeln PUID und PGID nutzt, dann lässt sich der Container starten.

Sieht dann wie folgt aus:

docker run -d \--name uptime-kuma \
-v /volume/docker/uptime-kuma:/app/data \
-p 3001:3001 \
-e PUID=[UID vom neuen Synology User] \
-e PGID=[GID von eine 08/15 DSM Gruppe] \
louislam/uptime-kuma

Wieso das jetzt funktioniert und ob es mein Anliegen (Container von meinen restlichen Volume und Daten auf der Synology isolieren), weiss ich noch nicht - Da muss ich noch recherchieren.

 

[alexhell]

Liest du eigentlich die Antworten? Ich zitiere mich mal selber

Es gibt Container die nehmen eine GID/GUID als Environment Variable an. Du kannst aber auch einfach den User in der Compose/per docker run Befehl festsetzen.

Das hängt ganz davon ab wie das Image erzeugt wurde. Die Variablen können auch anders heißen.