ElabNET Technik Forum

Vielleicht habe ich das auch nur übersehen...

Aus Sicherheitsgründen wäre es wünschenswert, wenn die Software in den Docker Containern nicht als root sondern unter einem eigenen Benutzer laufen könnte. Ein Benutzer für alle Container würde da fürs erste schon ausreichen, noch schöner wäre natürlich, wenn man mehrere Benutzer anlegen könnte.

Beispiel: Der openHAB Container wechselt beim Start auf den per Umgebungsvariable übergebenen Benutzer & Gruppe.

ByTheWay: das nicht verwenden von root ist auch seitens Docker empfohlen und best practise.

...aber wir haben bei unseren Anwendungen auch noch nicht alle umgestellt

Gruß Oliver

Der Docker nebst portainer läuft doch gar nicht unter Root?

Dafür gibt es den Benutzer "Portainer"?

Auch sollte man nicht auf die Systemressourcen kommen außer einem dafür vorgesehenem Plattenbereich


lg

Stefan

Jockel,

wenn du damit meinst unter welchem Benutzer die SW im Docker selber läuft, das wird über das Entry-Script gemacht und dafür ist der Ersteller des Containers zuständig.
Ich glaub man kann beim Starten aber auch ein anderes Entry-Skript angeben. Wenn das so ist, kannst du natürlich einen Wrapper mit dem Benutzer deiner Wahl machen, könnte aber schiefgehen, wenn das Entry-Skript noch Root-Rechte für bestimmte Einstellungen braucht.

Was aber wichtig ist:
Der Container teilt sich mit dem Host denselben UserID-(nicht User-Name)-Raum. Das kann gut sein, kann aber auch zu komischen Effekten bei gemappten Volumes führen. Wenn man sicher gehen will, dann legt man im Docker also UIDs an, die auf dem Host nicht existieren.

Hallo,

ja ich meine der Nutzer, unter dem die Software im Container läuft.

Ich bleibe wieder beim Beispiel openHAB, weil ich damit zur Zeit experimentiere. Der Container bekommt per Umgebungsvariable eine user und Gruppen-Id:

...
- e USER_ID=1004 \
-e GROUP_ID=1000 \
...

In der entrypoint.sh des Containers wird dann ein Benutzer openhab im Container mit der übergebenen User-Id und Gruppen-Id angelegt und openHAB per "gosu" unter diesem benutzer gestartet.

Die übergebenen User-id und Gruppen-Id müssen natürlich auf dem Timberwolf existieren und entsprechende Rechte auf den gemappten Verzeichnissen haben.

Mein Feature-request ziehlte darauf ab, dass ich auf dem Timberwolf einen Benutzer openhab (um beim Beispiel zu bleiben) anlegen und ihm die Rechte auf den zu mappenden Verzeichnissen zuweisen können wollte um dann dessen User-Id beim Start an openhab übergeben zu können. Für den nächsten Container, z.B. dovecot dann einen weiteren Nutzer "dovecot" mit gleichem Prinzip.

Alternativ und einfacher: Ein Benutzer "docker_user" der dann beim Start aller Container verwendet werden kann.

Wenn ich Dich richtig verstanden habe, ist der Beutzer "portainer" ja derjenige, unter dem Portainer selbst auf dem Timberwolf läuft, der sollte dafür nicht verwendet werden.

Viele Grüße,
Jockel

Wenn ich mich richtig erinnere (gefährliches halbwissen das hat ein Kollege programmiert), dann läuft bei dem Timberwolf Docker unter dem User portainer.
In dem Container wird dann ein Container Portainer gestartet. Ob der Portainer in seinem Container als root gilt kann ich dir leider nicht sagen. Da sich das aber sowiso nur auf den Container beziehen dürfte sollte das vermutlich aber nicht relevant sein.

Der User unter dem der von dir verwendete user selbst läuft, sollte meines Wissens wie Cepheus schon sagte über das Entry Script festgelegt werden, alternativ aber auch als Umgebungsvariable (also vermutlich unter dem Reiter ENV im Portainer). Bin diesbezüglich aber selbst noch in der Experementierphase.

Theoretisch sollte also nichts dagegen sprechen, dass du also den Containern dieselbe UUID (über env) zuweist und das als deinen "docker_user" verwendest. Die Freigaben kannst du ja dann immernoch über Volumes verwalten, oder sehe ich das falsch?

Das sollte doch ziemlich genau deinem alternativ und einfacher entsprechen (bitte korregiert mich falls ich mich irre, eigentlich bin ich deutlich fitter im Bereich Hardware).

------------------
das wars zum Thema

An dieser möchte ich kurz ausholen und euch kurz mal näher bringen was all das immer für einen Rattenschwanz in der Entwicklung nach sich zieht und wie ich den damals Zwischenstand mit dem User Portainer und dem Container mitgekriegt habe.
Wie gesagt eigentlich bin ich bei ElabNET für die Entwicklung der Hardware verantwortlich (Platinen für TW 950/960/2500/2600, auch die ersten Gehäuse usw.).
Auf jeden Fall wurde dann im Laufe der Entwicklung klar, dass wir neben der ganzen Sicherheitsaspekte in der Software in Verbindung mit dem Docker auch noch sicher stellen mussten das unsere Hardware sicher als unsere eigene erkennen müssen, da nun jeder einen FTDI mit X-beliebiger Funktion in seinen Docker Container evtl einschleifen will.
Also musste auf die Schnelle nicht nur die Softwareentwicklung sich überlegen wie wir das alles managen wollen. Nein ich musste den damals firsch modifizierten 2600 (von normalem FTDI auf DUAL FTDI, damit sich die Kollegen in der Produktion leichter tun, da dadurch wurde ein 20 poliges Flachbandkabel von der Apu zu meiner Platine eingespart) abermals modifizieren um einen EEPROM hinzuzufügen.
Doch damit nicht genug. Diesen Dual FTDI habe ich ursprünglich bei der Verbesserung der Hutschienenserie entdeckt. Das neu verwendete CPU Modul bot nicht genügend UARTs um all die Peripherie bedienen zu können. Es gab in einer passenden Größe jedoch nicht allzuviele Alternativen und zumindest keine die ich damals gefunden habe, die auch nur ansatzweise so leistungsfähig gewesen wäre.
Als aufmerksame Leser werdet ihr mit Sicherheit bereits herausgefunden haben -> da muss also jetzt da auch noch ein EEPROM drauf. Also auch das erledigt.
Zu allem Überfluss scheint es aktuell unmöglich absolut unmöglich Bauteile, die man eine Woche vorher für die Nullsereie bestellt hat für die Serienproduktion zu bekommen es ist wirklich wirklich jedes Detail (für euch) für uns ein immenser Kraftakt.

Allen Problemen zum Trotz die 2500 wurden mittlerweile fast vollständig ausgeliefert und für die 2600 sind mittlerweile fast alle Bauteile geliefert.

Zu 950/960: Direkt nachdem ich den EEPROM hinzugefügt habe, hat der Hersteller der CPU-Boards uns mitgeteit (vermutlich nach der 10. Nachfrage), dass in ca 1% der fälle die Boards nicht Booten, wenn der Boot nach Vorhandensein aller Spannungen nach weniger als 1,5 Sekunden erfolgt -> ich vermute ihr wisst was das heißt.

Wie dem auch sei, all das ist vergangenheit. Auch hier ist aktuell das Problem der Bauteilbeschaffung.


liebe Grüße, Julian

Der User unter dem der von dir verwendete user selbst läuft, sollte meines Wissens wie Cepheus schon sagte über das Entry Script festgelegt werden, alternativ aber auch als Umgebungsvariable (also vermutlich unter dem Reiter ENV im Portainer). Bin diesbezüglich aber selbst noch in der Experementierphase.

Damit der User im Entry Script gesetzt werden kann, muss die User Id auf dem Host aber schon existieren, da sich host und alle Container die gleichen Ids teilen (die aber im Container einen anderen Usernamen haben können. Mein Vorschlag war, auf dem Timberwolf User anlegen zu können, deren Id dann an den Container übergeben werden kann damit im Entry Script der Benutzer gewechselt werden kann. Hier ist ein ganz guterÜberblick über das Thema; https://medium.com/@mccode/understandin ... 37a01d01cf

Ansonsten: Danke für den Blick hinter die Kulissen, sehr interessant!

Ich bin ja selbst Entwickler (wenn auch Software) und kann gut nachempfinden, wie auch vermeintliche Kleinigkeiten einen riesigen Aufwand nach sich ziehen können, von dem der Kunde am Ende nichts sieht... Und ich freue mich auch immer, wenn ich vom Kunden höre "kann man nicht mal eben"

Daher ist mir auch ganz klar, dass nicht jeder Wunsch hier erfüllt werden kann und manche zumindest länger dauern. Ich denke aber, es ist trotzdem sinnvoll sie zu posten, eher im Sinne einer Sammlung, die dann von Euch bewertet werden kann.

@Julian: sehr schönes Posting mit einem sehr eindrucksvollen Einblick hinter die Kulissen!

Für mich ist das SmartHome ein nettes Hobby, beruflich bin ich in einer ganz anderen Branche unterwegs, umso mehr finde ich Einblicke in eure Welt spannend und neben dem Informationsaspekt zum TWS eben auch eine allgemeine Bereicherung!!!

Weiter so!
Lg
Robert

@Jockel: Noch eine Frage bevor ich das Thema in die FR Übersicht aufnehme:
Verstehe ich das richtig: Deine Sorge ist, dass der User "portainer" zu viele Rechte besitzt, so dass zumindest die Gefahr besteht, dass man sich mehrere Docker gegenseitig beschädigen können, denke dass die Docker keine root Rechte am TWS selbst besitzen.
Mit mehreren Usern könnte man die Rechte der Docker flexibler einschränken.

Trifft das den Hintergrund, oder liege ich hier weit daneben?

lg
Robert

Ja genau, das trifft es!

Die Docker container selbst sollten nicht als root laufen (wenn ich es richtig verstanden habe tun sie das auch nicht, sondern werden unter dem Benutzer "portainer" gestartet). Aber wenn alle Container und dem selben Benutzer laufen besteht die Gefahr der gegenseitigen Beeinflussung, insbesondere auch bei eventuellen Sicherheitslücken.

Den FR Request halte ich jetzt auch nicht für den allerwichtigsten überhaupt, denke aber schon, dass das irgendwann angegangen werden sollte. Aber nicht unbedingt bis zur 1.0.