[offtopic] Docker images und Zugriff auf Shares

Begonnen von bugster_de, 26 Juli 2018, 09:14:45

Vorheriges Thema - Nächstes Thema

bugster_de

#15
zu meinem Post oben: das Problem beim linuxserver/tvheadend Image is wohl bekannt:
https://github.com/linuxserver/docker-tvheadend/issues/44
https://blog.linuxserver.io/2017/02/19/how-to-set-up-tvheadend-with-your-dvb-t2-receiver/
dort empfehlen sie auch den Owner von /dev/dvb so zu ändern, dass der Container User darauf zugreifen kann.
Mir ist bei der Lösung auch nicht ganz wohl, aber momentan läuft der neue Server ja noch nicht im produktiven Betrieb und ich kann mal schauen, ob es eklige Seiteneffekte geben wird, bevor er produktiv geht. Wenn es keine Seiteneffekte gibt, dann gehe ich erstmal mit dieser Lösung.

Falls Seiteneffekte auftreten kann ich natürlich immer noch jede einzelne Karte mittels --device=/dev/dvb/adapterX an den Container übergeben.

bugster_de

#16
also, ich hab mich jetzt weiter rein gefuchst ind die Docker Geschichte, aber das Thema mit den User Mappings ist doch nicht ganz so leicht.

Wenn ich einen Apache2 Container aufsetze, sieht mein Dockerfile wie folgt aus:
FROM httpd:2.4
COPY ./mydata /usr/local/apache2/htdocs/
USER 1003:1003

der User 1003 ist dabei der User dkr_apache auf dem Host System. Somit sollte nach meinem Verständniss der root im Container (UID=0) auf den user dkr_apache (uid=1003) auf dem Host System gemapped werden.

Wenn ich nun
sudo docker build -f ./Dockerfile -t my_apache2 .
sudo docker run -it --name=apache -p 28080:80 my_apache2

mache, dann erhalte ich die Fehlermeldung:
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80

Ich brauch da mal einen Gedankenstoß, da ich offensichtlich auf dem Schlauch stehe.
Darf der User 1003 auf dem Host System den Port 28080 nicht nutzen? Ich habe extra einen sehr hohen Port zum Test genommen
Oder ist der User im Dockerfile der User der im Container dann die Scahen ausführt? Und wenn ja, wie mappe ich dann den root des Containers auf den 1003 user des Host?

Und wenn ich Dockerfile die Zeile User 1003:1003 weglasse und statt dessen
sudo docker run -dit --name=apache --net=bridge -u 1003:1003 -p 28080:80 -v /mount/int/hd02/0_High/1_Appdata/apache/:/mmdata my_apache2
gehts auch nciht, da der Apache im Container dann ebenfalls nicht hoch kommt.

Und ohne die -u Option
sudo docker run -dit --name=apache --net=bridge -p 28080:80 -v /mount/int/hd02/0_High/1_Appdata/apache/:/mmdata my_apache2
wenn ich dann im Container eine Datei in /mmdata anlege und diese dann auf dem Host System anschaue, dann wurde sie von root erzeugt :-(

in der /etc/docker/daemon-json habe ich:
"userns-remap": "root",
und die /etc/subuid sieht so aus
root:100000:65536

Wernieman

Ports unter 1024 darf nur root anlegen.

Lies Dir mal die Fehlermeldung durch:
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

Hi,

danke!
Sprich im Container muß ich apache als root laufen lassen oder Apache auf einen Port > 1024 loslassen oder aber den container mit dem User 1003 und --cap-add starten.

Aber wie schaffe ich es, dass im Container root mit der UID = 0 auf dem Host auf den User dkr_apache mit UID = 1003 gemappt wird? Denn das wäre mir eigentlich am liebsten.

Wernieman

Da wir hier docker mit der Gruppe docker laufen lassen (wird irgendwann zu kupernetis oder docker swarm migriert) kann ich es Dir nicht sagen ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

#20
Hi,

das heisst ihr führt alle docker Befehle als user docker in der Gruppe docker aus? Sprich dieser User hat dann Zugriff auf den Docker Daemon?

P.S.: ich habe mir jetzt ein eigenes Docker-Image auf Basis Ubuntu:18.04 mit installiertem Apache zum rumprobieren gebaut. Das geht eigentlich schon mal ziemlich gut und hat den Vorteiu, dass ich weiß, was darin konfiguriert wurde und wie ich es umfummeln kann. Scheint zumindest zum Lerne, was bei Docker wie zusammen hängt für mich der Weg im Moment. Bei heruntergeladenen Images wusste ich nicht so ganz genau, ob es jetzt an mir liegt oder das Image entsprechend konfiguriert ist.

P.S.2: sollen wir diesen Thread mal nach Off-Topic verschieben oder hier lassen? Da es jetzt seit kurzem ja ein offizielles FHEM Docker Image gibt würde ich mal vermuten ich bin dann nicht der einzige, der diese Fragen stellt.



Wernieman

Wieso "docker-Befehle"?
ein Docker-Container ein Dienst. Teilweise kümmer sich auch der docker-Deamon um ein start eines Containers, wenn dieser "weg" ist. Als reiner Server-Dienst haben wir damit keinen einzelnen docker-Befehl ... oder ich verstehe Dich jetzt falsch ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

wenn ich als normaler user folgendes mache:
docker start my_apache
dann kommt eine Fehlermeldung
wenn ich aber
sudo docker start my_apache
mach, dann geht es.  Sprich der root darf die Docker Befehle ausführen, mein normaler User nicht, was so auch erstmal richtig ist.

Wenn ich dich richtig verstehe, dann habt ihr euch einen User names docker angelegt, diesem die Rechte gegeben die obigen Befehle auszuführen und somit wird der Conatiner dann unter dem User docker ausgeführt. Richtig verstanden?

Übrigens: ich hatte einen Denkfehler drin: innerhalb des Containers wird der Apache natürlich NICHT als root ausgeführt sondern als www-data

Wernieman

Wenn ein User in der Gruppe docker ist, kann er Container starten/stoppen.

Aber Achtung: Durch einfaches Tricksen kann er sich über ein Container auch root-.rechte beschaffen
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

ha, Danke ! So langsam kommt Licht ins Dunkel. Ich befürchte aber, dass bei mir im Kopf die verschiedenen Docker- und Host-User noch zu nebulös durcheinander gehen, so dass ich noch nicht mal mein Problem sauber beschreiben kann

Wenn ich also sudo usermod -aG docker horst mache, dann darf der User horst docker start my_apache ohne sudo ausführen. Und nun hätte ich erwartet, dass der User root im Container sich auf den User horst auf dem Host mappt. Dem ist aber nicht so. Root im Container ist auch root auf dem Host.

Es wäre aber genau mein Wunsch, dass root im Container sich auf den horst auf dem Hostsystem mapped, denn kann ich dem Horst nur genau die Rechte auf dem Host geben, die er zur Ausfürhung seiner Aufgabe braucht. Da jeder Container tendenziell ein single-trick-pony sein soll, braucht man natürlich auch für jeden Container dann einen User. Initial viel Aufwand, aber die einzelnen Rechte lassen sich fein granular zu teilen.

Wernieman

#25
Security-Technisch sollte man wissen, das es relativ einfach ist, aus einem Container auszubrechen. Anders als z.B. bei einer Virtuellen Maschine.

Sicherheitstechnisch ist die Relation:
nativ auf der Maschine <-> Docker <-> VM

Eigentlich machst Du es eigentlich über die Zuordnung der Fileysteme, d.h. ein Image bekommt nur die Pfade zu sehen, welche es braucht. Eine Zuordnung z.B. über / wäre deshalb ...... negativ

Mann kann per Docher auch einen Container auf einem eigenen User mappen lassen .... nur damit habe ich keine Erfahrung ...
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

#26
Oh Mann, jetzt ist bei mir der Groschen gefallen. Der ist sogar so laut gefallen, dass ihr das bestimmt durch das Internet hören konntet :-) Ich schreib das jetzt hier mal nieder als Merker für mich selbst mit der Bitte um Korrektur, falls es doch immer noch nicht stimmt (und ich den Groschen wieder aufheben muß)

Im Prinzip ganz einfach. Ich möchte einen Container mit Apache drin haben. Dazu gibt es auf dem Host einen user namens docker_apache der z.B. die UID 1003 und GID 1003 hat.
In der /etc/docker/daemon.json trägt man dann "userns-remap": "docker_apache", ein. In der /etc/subuid bzw. /etc/subgid trägt man docker_apache:1003:65536 wobei die 1003 hier auch eine beliebig andere Zahl sein kann, aber wenn man die gleiche Zahl nimmt, dann kann man die Rechte auf dem Host mittels dem Namen (hier docker_apache) setzen und muß nicht die UID aus dem subuid nehmen.

Nun kann man den Container mittels docker run bauen. Das muß dann nichtmal mit dem User docker_apache passieren sondern kann jeder andere User sein, der zu der Gruppe docker gehört. Und nun wird der User root im Conmtainer auf den User docker_apache auf dem Host gemapped. Das sieht man z.B. daran, wenn man innerhalb des Containers als root eine Datei in einem Volume erzeugt. Innerhalb des Containers gehört die Datei dem root:root, auf dem Host System gehört sie docker_apache:docker:apache.

Soweit so gut. Aber: da ich nun den Conatiner mit -p 80:80 starten kann heisst das, dass der User, mit dem der Container gestartet wurde offensichtlich das Recht hat auch Ports < 1024 in Beschlag zu nehmen. Das muß dann wohl durch die Gruppenzugehörigkeit docker erreicht worden sein.

ZitatSicherheitstechnisch ist die Relation:
nativ auf der Maschine <-> Docker <-> VM
auch dieser Groschen fiel jetzt. Ich komme halt eher aus der VM Welt und Docker hat dazu im Vergleich weniger Trennung zum Host System.

ZitatEine Zuordnung z.B. über / wäre deshalb
das ist bei obigem schon mal eminent wichtig, aber somit kann ich
1.) nur Folder zuordnen, die für den Container wirklich gebraucht werden
2.) dem Folder die entsprechenden Rechte geben

Ich muß mich jetzt aber nochmal zurück lehnen und neu überlegen, ob Docker der Pfad meiner Wahl ist. Als Ziel hatte ich vorranging eine bessere Wartbarkeit meines Servers, da nicht jedes update auf dem Server gleich in das große Zittern ausartet, ob den nun noch alles geht. Das ist mit Docker auf jeden Fall erreichbar. Eine Verbesserung der Sicherheit kommt auch mit, aber nicht in dem Maße, wie es z.B. eine VM hätte. Docker erhöht die Sicherheit aus meiner Sicht vorallem dadurch, dass es für einen Angreifer erstmal undurchsichtiger ist, mit was er es zu tun hat und dann benötigt er noch das entsprechende Wissen, um aus der VM auszubrechen.
Um aber vorallem die Wartbarkeit des Containers sicher zu stellen müssen die Datzen und Konfigurationen aus dem Container raus genommen werden (Volumes). Also bei Apache z.b. /var/www/html, damit man dann bei Bedarf den Container auf Basis eines neuen ubuntu:latest mit apt-get upgrade im Dockerfile neu bauen kann.

Wie gesagt es gibt noch vile zu lernen, aber so starte ich esrtmal, denn mit diesem Setup kann ich zukünftig auch noch umbauen, wenn meine Lernkurve weiter hoch geht

Wernieman

Genau, alle Pfade mit persistenten Daten (z.B: auch bei DBs) dürfen nicht im Docker-Image liegen, sondern durch Volumen" rausgelinkt sein. Entweder auf dem Host-Dateisstem oder auf docker-volumen. Sonst bekommt man ein Geschwindigkeitsproblem, welches auch so bei der Docker-Doku erwähnt wird.

Gegenüber VMs hat docker den Vorteil, das kein Komplettes 2. System laufen muß, sondern nur die "nötigen" Libarys. Auch kann der SPicher dynamischer verwaltet werden, bei VMs geht er schneller "weg".

Grundsätzlich:
Lies Dich mal in "docker-compose" ein. Wird von den meisten Stiefmützterlich behandelt, macht aber langfristig das Leben einfacher. Mit einer docker-compose.yml kannst Du dann ein "Ökosystem aufbauen". z.B. ein LAMP-System mit DB + Apache in einem Eigenen Netzwerk. So hast Du auch eine Abschöttung, das z.B. der DB-Server nur vom Apache erreichbar ein muß.

Am Anfang schwieriger, am Ende einfacher. Habe hier z.B: ein Zulip-Container per docker-compose aufgebaut, damit ein Update/Neustart (oder Umzug) einfach schneller (und einfacher) geht. Gleichzeitig auch eine Doku, wie die Container gestartet werden.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

bugster_de

Danke. Das Docker-compose steht bei mir eh als nächstes auf der Liste der Einarbeitung, da es sich für mich vorallem mal wie eine gute Möglichkeit angehört hat, mehrere Container, die zusammen gehören auch in einem Rutsch inklusive definierten Startreihenfolge zu starten. Also zuerst den mysql un dann erst Wordpress.

Der ganze Plan sieht wie folgt aus:
- es gibt einen container mit Apache, welcher als Proxy-Server dann von aussen erreichbar ist (deshalb auch der User Heck-Meck). In diesem Container ist nur Apache ohne PHP oder sonstwas drin und er routet nur auf die jeweiligen Container basierten Anwendungen dahinter oder auch die Anwendungen, die auf einem anderen Rechner im Haus laufen (z.B. FHEM). Nach aussen ist auch nur Port 443 für https mit eigenem Zertifikat offen.
- für jede Anwenung gibt es einen Schwung von containern. Z.B. einen Container für Wordpress der seinen eigenen Container für mysql hat. Genauso dann einen für owncloud mit einem eigenen mysql Container, was dann das fein-ziselierte Backup sowie Wartung erleichtert. Diese zusammengehörenden Container (z.B. owncloud mit seinem mysql) müssen dann mittels docker-compose zusammen gefasst werden
- manche Anwendungen brauchen auch nur einen Container (z.B. tvheadend, plex), dann geht das auch ohne compose

Performance beim Zugriff von aussen ist nicht ganz so entscheidend, da ich ja eine sehr limitierte Anzahl an Usern drauf habe und von denen ich mit Abstand der Power-User bin. Einzi der TV Zugriff von aussen braucht vermutlich ganz gut Durchsatz, wobei dies genau der Hauptgrund für den neuen Server ist: encoding in real-time. Sprich der Container encoded den Stream und reicht dann h265 nach aussen weiter

Performance beim Zugriff innerhalb des Netzes ist vermutlich schon entscheidender, denn hier nutzt die ganze Familie die komplette Bandbreite an Multi-Media Möglichkeiten voll aus. Bisher ging ich dabei nicht davon aus, dass auch hier ein Proxy Server dazwischen muß, denn die Mediendateien etc. sind auf dem Server alle read-only gesetzt, so dass auch ein Virus, der von aussen mittels Laptop eingeschleppt wurde die Daten wohl eher nicht zerstören oder verschlüsseln kann. Die Shares sind im Netz auch nicht sichtbar, sprich man kann auch nicht nach ihnen suchen sondern muß sie schon kennen und auch den entsprechenden User plus Passwort wissen.
Im Rahmen der Möglichkeiten sollte ich doch damit gegen Script-Kiddies etc. geschützt sein, oder? Einen professionellen Angreifer, der wirklich Energie und Tage lang Arbeit rein steckt wird das nicht aufhalten können, aber da frage ich mich, warum ich ein Angriffsziel sein sollte.

Router ins Internet ist auch keine Massenware wie Fritzbox oder Telekom Router (auch wenn die echt top sind)







FunkOdyssey

Anstatt Apache2 würde ich es mit folgenden Lösungen machen:
https://github.com/jwilder/nginx-proxy
https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

In der YML sind es nur 2-3 Zeilen, die für den FHEM-Zugriff ergänzt werden müssen. Ganz einfach.