|
|
|
|
|
|
|
Ja, ist ein inhärentes Problem von der Docker-Architektur.
Das Problem sind aber nicht die Dienste (gut gemacht Dienste wechseln den User). Das Problem worauf das Arch-Wiki raus will: Wenn du einen User im System hast, der NICHT root werden kann (z.B. nicht in der sudo-Gruppe) aber in der docker-Gruppe weil er Container verwalten soll. Dann ist er effektiv doch root. Eben weil er einen Container starten kann der als root läuft und er sich dann an diesen attached. Dann noch das Dateisystem reinmounten: Bingo.
Einfach so:
| |
| Code: |
docker run -it --rm --privileged -v "/:/mnt/root/" ubuntu /bin/bash
|
|
Wen das wirklich stört, der kann sich ja mit dem neuen Trend podman beschäftigen. Die bringen die komplette Container-Infrastruktur in den User-Space.
// Btw: Je nach Dienst, musst du eh als root laufen, weil der User JohnDoe keinen WebServer auf Port 80 lauschen lassen darf. Oder du baust ein komplexere Reverse-Proxy-Setup. Aber das muss dann wieder root konfigurieren, wenn sich was ändert 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 16.02.2021 11:33]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Auf podman bin ich jetzt inzwischen auch gestoßen, aber da muss man laut Arch Wiki ja auch bisschen Aufwand betreiben, bis man damit Container ohne root laufen lassen kann.
Port 80 etc wäre jetzt nicht das Problem, da ich auch nen Reverse Proxy im Einsatz habe.
Aber ich verstehe langsam, dass es nicht so einfach ist das als nicht-root laufen zu lassen. Danke für eure Einschätzungen 
|
|
|
|
|
|
|
|
|
|
|
wenn du docker mit --privileged startest dann sind die prozesse dadrin praktisch auch root auf dem host.
ansonsten nur root im container, was irgendwie auch nicht favorable ist aber ich noch nicht ganz schlau bin was das denn heisst...
aber ja, jeder benutzer dem du docker rechte gibts ist root auf deinem host, beispiel gefällig?
| |
| Code: |
$ ls /hallo_du; docker run --rm -it -v /:/work debian:buster touch /work/hallo_du; ls /hallo_du
ls: Zugriff auf '/hallo_du' nicht möglich: Datei oder Verzeichnis nicht gefunden
/hallo_du
|
|
e: mäh, jetzt erst gesehen dass die diskussion ja schon eine seite weiter ist. genau das beispiel kam natürlich auch schon 
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [KdM]MrDeath am 16.02.2021 12:41]
|
|
|
|
|
|
|
|
|
Jop, docker-user ist defacto-root.
Zum Rest: Docker-Rootless wollte ich seit Ewigkeiten schonmal anschauen, aber ich kam noch nie so recht dazu.
Was man aber machen kann: nicht einfach `--privileged` verwenden. Eigentlich: nie `--privileged` verwenden, außer man weiß, was man tut.
Wenn möglich, "einfach so läuft ja Images" von $random_dude_auf_github genau anschauen / im Zweifel lokal selbst bauen, statt einfach nur pullen.
Wenn möglich, Images schnappen, in denen der Dienst darin nicht mit root läuft / die privileges droppt. Wenn's nur um "niedrigen Port" geht, kann man auch mit authbind oder setcap arbeiten.
Und was ich quasi "per default" nutze, ist die userns-remap-Funktionalität: https://docs.docker.com/engine/security/userns-remap/
Ja, das macht es oft frickelig(er) (insb. wenn man Volumes shared / lokale Ordner als Volumes verwendet), ist aber m.E. den Aufwand wert. Sinngemäß: die User/Groups in den Containern entsprechen nicht den Nutzern auf dem System; schafft man es, aus einem Container auszubrechen, hat man auf dem Host-System erstmal 0 Rechte.
Und wenn man's noch mehr "fine grained" haben will, kann man seccomp-Profiles erstellen/anpassen und den jeweiligen Containern mitgeben.
--
Unterm Strich also: Docker-Isolierung niemals als grundsätzliches Sicherheitsfeature betrachten*. Dabei ist es aber möglich, trotzdem einen gewissen Sicherheitsgewinn gegenüber non-dockerized Diensten zu erreichen, wenn man weiß, was man tut.
Damit meine ich: Nicht irgendetwas nehmen, dem man sonst auch nicht recht trauen würde, und dann annehmen, es sei schon "ordentlich sandboxed", weil's ja im Container läuft. Sachen, die man aber auch so laufen lassen würde, kann man darin dann "schön getrennt" nutzen, und dabei tatsächlich einen gewisses Maß an extra-Sicherheit gewinnen.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von FuSL am 16.02.2021 12:02]
|
|
|
|
|
|
|
|
|
bei all dem aufwand sollte man halt auch echt abwägen ob sich "der dockeriteil lohnt".
alles was du schreibst ist für services gut und recht und kann (viel einfacher und "gewollter") mit systemd bordmitteln erreicht werden.
bei docker kämpft man da irgendwie "gegen das system" und muss diese funktionalität dem ding eher abringen, als dass es einen dabei unterstütz.
dazu kommt noch dieser unsägliche docker daemon, ich mach drei kreuze wenn sich so alternativen wie podman mal großflächig durchgesetzt haben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 16.02.2021 12:48]
|
|
|
|
|
|
|
|
|
Also man sollte sich schon im klaren sein: Das Ziel von Docker ist NICHT security!
Das Ziel von docker ist ease of use.
Ich nutze das z.B. um auf meiner lokalen Entwickler-Kiste eine aus 25 Microservices bestehende Cloud-Anwendung laufen zum lassen in einem lokalen Developer-Environment. Mit alle schnick schnack: Postgres, EventStoreDB, RavenDB, MQTT-Broker, RabbitMQ.
Will ich das alles händisch auf meinem System aufsetzen? NEIN! Um himmelswillen!
(Mal abgesehen davon, dass ich neben dem System noch 3 andere Kunden-Entwicklungen betreue. Mal mit MariaDB oder mal mit SQL-Server. Und es einfach grandios ist, dass ich am Ende auch einfach 20 Postgres laufen haben kann, ohne das diese sich ins Gehege kommen)
Und genau da schlägt die Stunde von docker: "docker-compose up" und das Zeug läuft und ich kann entwickeln.
Will man das so hosten? Eher nicht.
Zugegeben: Ich hoste z.B: auch ein privates gogs aus einem Container raus. Aber eben dann hinter einem ReverseProxy. Eben weil es geschickt ist, schnelle einfache Testballons zu starten. Dadurch das der Container "self contained" ist, sind upgrades für den Entwickler als auch den User wiederum viel bequemer. Wenn das OpenSSL im Container aber einen Bug hat: Ja dann biste halt gefickt, bis jemand ein neues Image baut.
Hat halt alles Vor- und Nachteile.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 16.02.2021 12:57]
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Also man sollte sich schon im klaren sein: Das Ziel von Docker ist NICHT security!
| |
Jenes.
@[KdM]MrDeath
Kann man, bestimmt – und ist je nach Rahmenbedingungen sicherlich auch genauso legitim.
Es nimmt aber eine Menge an "sonstigem Gefrickel" raus – Abhängigkeit x die auf Debian-xyz Version 1.2.3pre-backported-1987-fix-extra-patch-workaround hat, aber Version 1.2.4 bräuchte; drölf Dienste, die man so dann entspannt mit eigenen DBs laufen lassen kann / sich weniger um Ports streiten kann usw.
Alleine zum Deployen von Rails-Sachen mit allem Drumherum, native Dependencies usw. lohnt sich's (für meine Zwecke) schon immens [edit]und auch das Verwalten mehrerer Web-Dienste mit nginx-Proxy & Co. finde ich in dieser Form entspannter[/edit].
Eben das: Ich habe hier Sache X, und es ist mir relativ wurscht, ob das auf DebianX/UbuntuZ/CentOS/Alpine laufen muss.
Auch hier natürlich weniger mit "man nimmt einfach vorgefertigtes Image Y", sondern bevorzugt mit selbstgebauten Images und compose-Files – weil man so auch solche Sachen wie GH@NDI beschreibt (veralteter Kram in Containern/Images) im Griff hat.
Wer so nicht an die Sache rangeht, sondern eben die "geilo, $image von irgendwem von irgendwo hat alles"-Variante nimmt und nie mehr draufschaut, der lässt halt im Zweifel irgendwelchen fragwürdigen Code von irgendem mit potenziell uralten Lücken maximalprivilegiert auf seinem System laufen ^^
…wie so oft also ein "kommt drauf an, was man braucht / kann / will" ^^
Am Rande: Auch wenn es hie und da berechtigte Kritik an manchen systemd-Aspekten geben mag: gelegentlich bin ich tatsächlich positiv überrascht, was damit mittlerweile alles recht gut geht (insb. eben auch mit Diensten, Berechtigungen und Isolierung).
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von FuSL am 16.02.2021 13:13]
|
|
|
|
|
|
|
|
|
| | Zitat von GH@NDI
Postgres, EventStoreDB, RavenDB, MQTT-Broker, RabbitMQ.
| |
Samma. Findest du nicht noch ein paar message queues, die du mit reinnehmen kannst?
|
|
|
|
|
|
|
|
|
|
|
|
Bestimmt läuft da auch noch CoAP, aber dafür braucht er ja keinen Container als Broker
|
|
|
|
|
|
|
|
|
|
|
|
also ich hötte noch nen ZMQ proxy und crossbar.io mit reingepackt!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
| | Zitat von GH@NDI
Postgres, EventStoreDB, RavenDB, MQTT-Broker, RabbitMQ.
| |
Samma. Findest du nicht noch ein paar message queues, die du mit reinnehmen kannst?
| |
Das passiert, wenn du mit der echten Industrie echte Lösungen integrieren möchtest.
Ich war überrascht, aber z.B. in der Aufzugsbranche ist MQTT total der angesagte heiße scheiß. Ich finds fürchterlich
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
bei all dem aufwand sollte man halt auch echt abwägen ob sich "der dockeriteil lohnt".
alles was du schreibst ist für services gut und recht und kann (viel einfacher und "gewollter") mit systemd bordmitteln erreicht werden.
bei docker kämpft man da irgendwie "gegen das system" und muss diese funktionalität dem ding eher abringen, als dass es einen dabei unterstütz.
dazu kommt noch dieser unsägliche docker daemon, ich mach drei kreuze wenn sich so alternativen wie podman mal großflächig durchgesetzt haben.
| |
Ich bin (leider) nicht im Containergeschäft, habe aber aufgeschnappt, dass die Konstruktion als Daemon und der Betrieb mit Superusersrechten immer eine Kritik an Docker war. Podman scheint wohl der Gegenentwurf zu sein und mit der Unterstützung von Red Hat?
| | Zitat von [KdM]MrDeath
| |
Conclusions
Docker containers are, by default, quite secure; especially if you run your processes as non-privileged users inside the container. | |
https://docs.docker.com/engine/security/security/
jo, nuff said. das ist genau das was man braucht, _im_container restriktionen wie was zu laufen hat um "sicherer" zu sein...
| |
Nachdem man so viele Jahre am "rootless" X gearbeitet hat ist mir das bei Docker nicht begreiflich. Ist irgendwo festgehalten, wieso sie das vertretbar fanden? Ich weiß aus meinen Notizen zu "Control Groups per Hand", dass ich selbige als Root erstellen muss und dann die Verantwortung an einen beliebigen User übergeben kann.
|
|
|
|
|
|
|
|
|
|
|
Hier wurde doch Rich erwähnt? In dem Zuge bin ich über Notcurses gestolpert und habe eine irrtümlicher Weise eine ähnliche Präsentation erwartet.
Und dfrs als TUI Ersatz für df.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 16.02.2021 16:53]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Das find ich auch gut.
|
|
|
|
|
|
|
|
|
|
|
Guten Tag. Ich lasse den Scheiss einfach auf Azure laufen.
Grüsse, Günter.
¤: Und bevor einer reinschleift: Die ganzen Securityconcerns sind die absolute Hölle, besonders wenn man lokale Datenspeicherung garantieren will. Ich kann es niemandem empfehlen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 16.02.2021 19:00]
|
|
|
|
|
|
|
|
|
|
Ich mag lxc container. Und möchte meine Mama grüßen.
|
|
|
|
|
|
|
|
|
|
|
Wenn ich machen könnte was deine Mama mag, dann sehe die Architektur anders aus.
Leider ist die Realität eine ganz andere, und man muss eine massive Abwägung (hehehe) zwischen Entwickler- und Runtimesystem finden, die in der Regel nicht einfach ist. Ich bin ja sowieso der Meinung, dass Dev und Ops viel mehr konvergieren sollten und probiere aktuell das auch immer so aufzubauen. Aber dann hast du halt auf der anderen Seite Sachen, die seit 20 Jahren so laufen und einfach eine absolute Katastrophe sind. Lösung? Keine.
|
|
|
|
|
|
|
|
|
|
|
dev und ops konvergieren?
ich weiss nicht...
ich behaupte von mir mittlerweile in wenig "beide seiten" gesehen zu haben und bin von entwicklern da eher nicht überzeugt.
man will immer alle rechte, aber hat eigentlich keine ahnung.
da kriegt man nichtmal ne ip adresse/zusätzliches vlan auf dem eigenen rechner konfiguriert weil basic netzwerkkentnisse fehlen aber man muss natürlich das produktivsystem voll unter kontrolle haben...
das reicht von so (zwar andere ecke, aber passende geschichte) entwicklern die nen ip adress change (jaja, nicht fragen) nicht hingekriegt haben und dann denken sie hätten "den fehler in unserm setup gefunden" weil da ne netzmaske von 255.255.252.0 ist. "das müsse auch ne 255 sein, ganz sicher, da kann nix anderes stehen"
usw.
insofern, ich entwickel gern und bin aktuell auf der seite, aber bei vielem heisst es einfach "schuster, bleib bei deinen leisten".
und dann fix ich auch gerne ab und zu den switch im büro wenn mal wieder jemand alle vlans runtergelöscht hat.
|
|
|
|
|
|
|
|
|
|
|
Jo, dito, und ich komme ja selbst von der (Entwickler) Seite. Aber wenn es keiner geschissen kriegt nur den Build irgendwie hinzukriegen, setze ich die Latte inzwischen da an (jaja, ich weiss, hehe) dass man immerhin genug Verständnis vom System hat, dass wenigstens das klappt.
Ich kann echt kein Verständnis mehr dafür aufbauen, dass man als Entwickler nicht mehr versteht, wo der Scheiss dann läuft. Und darum finde ich Docker auch so toll, weil man den Scheiss lokal laufen lassen kann. Du hast die Möglichkeit das zu fixen bevor es überhaupt irgendwo in die Pipeline geht, also nutze Sie auch.
¤: Okay, als kleiner Disclaimer vielleicht noch: Ich habe seit Jahren nur noch mit Verteilten / Cloud Projekten zu tun. Wenn man sich nicht bewusst ist womit man da arbeitet, ist halt schon Sense bevor etwas anfängt. Aber wenn jemand sich dessen in diesem Umfeld nicht bewusst ist, ist halt essig, weil garantiert nichts laufen wird.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 16.02.2021 19:37]
|
|
|
|
|
|
|
|
|
| | Zitat von statixx
Anyway. Gibt's evtl. Meinungen zu dem oben geposteten Dell-Mopped?
| |
Oh. Wir sind irgendwie vom deiner Frage abgewichen. Bekommen wir dann auch Bilder vom erworbenen Stück?
| | Zitat von a1ex
16:10 war mir mal wichtig bei fullhd. 1200 sind da ein echter Gewinn in der Höhe.
Wenns größer wird... meh.
Viel schlimmer finde ich dass nur Asus halbwegs gute Panels mit Fokus auf lag/hz verbaut... aber in so kackhässlichen Geräten dass man die trotzdem nicht kaufen kann.
| |
Dazu passend verdichten sich die Hinweise, dass das X13 Gen2 dem X1 folgt und auf 16:10 umstellt. Gerade bei den kleineren Displays ist das eine Verbesserung, bei ohnehin größerer Pixelfläche ist der Effekt kleiner.
Gleich adoptiert. Danke
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 17.02.2021 15:21]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FedEx? Keine Angst, Tom Hanks kümmert sich persönlich.
|
|
|
|
|
|
|
|
|
|
|
|
Zum Glück wohnst du nicht in der Schweiz, sonst käme das noch von mir.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Virustotal meint zwar nichts zu dieser Website, aber ich würde sagen, der Bot kann weg?
|
|
|
|
|
|
|
|
|
|
|
Da meine onboard Soundkarte kaputt ist, benutze den Klinkenausgang vom Bildschirm. Der hängt wiederrum per Displayport an der AMD Grafikkarte.
Hat hier jemand ein ähnliches Setup? Hab damit Probleme unter Arch. Mit PulseAudio schien manchmal etwas mit Frequenzen falsch zu laufen, so dass ich starkes Rauschen im Ton hatte. Bin jetzt zu PipeWire gewechselt. Da tritt dieses Problem nicht mehr auf, aber nach dem Hibernate ist manchmal der komplette Audioausgang einfach weg. Ich kann den dann wieder herbeizaubern indem ich ein bisschen TTYs wechsel oder pipewire neustarte...
Irgendwelche Tipps? Einfach neue Soundkarte kaufen?
Linux user trying to have sound... 
|
|
|
|
|
|
|
|
|
|
|
|
Ich habe ja einfach einen USB DAC. Bitte, habe gerne geholfen, und grüsse die Mama von Statixx.
|
|
|
|
|
|
|
|
|
|
|
|
An nem schweineteuren Ultrawide funktioniert der Audio-Ausgang bestimmt auch besser!
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
