Von Verfluchtnochmal_5987108 am Do, 3. Oktober 2019 um 19:36 #
Nun, viele Kommentare hier und allgemein gehen in die Richtung
Das was docker isolationstechnisch leistet kann ein systemd unit genauso gut und vernünftige Software braucht nicht genau Version x von library y kombiniert von z
Von Verfluchtnochmal_5987108 am Sa, 5. Oktober 2019 um 17:21 #
Faszinierend wie wenig Ahnung man haben kann und wie laut man das raus schreien muss! Die namespaces machen weder docker noch systemd selbst, das sind lediglich Schnittstellen zum Kernel
Sorry, aber wer 2019 noch initscripts benutzt hat sich in die falsche Branche verlaufen
Vor allem in Kombination mit PermissionsStartOnly kannst du damit in ExecStartPre und ExecStopPost mit vollem root Rechten agieren und den eigentlichen Dienst trotzdem maximal einschränken
Einfach mal RTFM und in 2019 ankommen bevor es vorbei ist
Von Verfluchtnochmal_5987108 am Do, 3. Oktober 2019 um 19:42 #
Und ja auch du hast in deinem ersten Post von "Sicherheitslücken schwerer auszunutzen" gesprochen während das Gegenteil wahr ist, die scheiss container sind üblicherweise mies gepflegt was enthaltene libraries betrifft und inflationär eingesetzt ist das ein horror
Aber nachdem du wie du sagtest ja eh kein admin bist wozu erzähle ich das einem "devops" der ohne container keine testumgebungen aufzusetzen im stande ist
Du musst schon die Container benutzen, die passen. Also für einen Server nicht die Entwicklercontainer nehmen. Und wenn du noch höhere Ansprüche hast, dir z.B. ein Alpine Linux nicht genügt, ja mein Gott - dann beginnst du halt "FROM scratch", machst weiter mit "ADD Verfluchtnochmal_5987108.tgz".
Trotzdem bleibt das getestete Software in einer minimalen Umgebung - normalerweise direkt vom Open Source Projekt konfiguriert und paketiert. Ohne Seiteneffekte, die deine Konfiguration zerlegen könnten. Mit nur den absolut notwendigen Schnittstellen nach draußen. Und das System kannst du auf deiner Hardware dann auch gleich mehrfach und trotzdem getrennt laufen lassen.
Weil du aber alles besser weißt und neben deinem abstoßenden Namen hier auch noch alle möglichen Leute durchbeleidigst (heute bin ich es wohl), werde ich ab jetzt nicht mehr auf auf deine scheinbar tiefsinnigen Posts antworten.
Ich bleibe dabei "Sicherheitslücken sind schwerer auszunutzen", es sei denn, du compilierst und paketierst alles selbst - und zwar anders als die Distributionen (damit Standard-Exploits möglichst nicht mehr durchlaufen). Aber das kannst du auch mit Containern machen. Siehe oben. Du splittest dein System halt auf, wenn auf einer Maschine unterschiedliche Dienste laufen.
Und gleich nochmal - ich habe nie behauptet, dass das der einzige Weg ist, Dienste zu isolieren. Und ich habe nie behauptet, dass das immer sinnvoll ist. Es ist aber praktisch mit den in sich getesteten Softwareeinheiten, die nun problemlos in Größe und Funktion kombiniert werden können und die Container werden auch nicht mehr verschwinden.
Von Verfluchtnochmal_5987108 am Fr, 4. Oktober 2019 um 04:42 #
Zur Isolation verwendet man VM's, die werden auch nicht verschwinden und ja ich baue software für Dienste die im Netz hängen selbst so optimiert und gehärtet wie nur möglich plus alles was systemd an Sicherheitsoptionen hergibt und schreiben run wir die darauf laufende Software auch seit ich denken kann selbst, heute nennt man das wohl DevSecOps
Container sind kein ausreichendes Sicherheitsfeature - PUNKT
Hat das wer behauptet - FRAGEZEICHEN
Was ist das überhaupt für eine Aussage. Ein Login ist auch kein ausreichendes Sicherheitsfeature. Und du schon garnicht.
PS:
Von dir brauch ich nicht wirklich eine Antwort.
Nun, viele Kommentare hier und allgemein gehen in die Richtung
Das was docker isolationstechnisch leistet kann ein systemd unit genauso gut und vernünftige Software braucht nicht genau Version x von library y kombiniert von z
Ein systemd unit? ????????????
Ja, eine systemd unit entspricht in etwas 10 Kilo systemkritsche Kernelbugs. Der Umrechnungskurs ist schon lange stabil. Ist ja kein Bitcoin.
Faszinierend wie wenig Ahnung man haben kann und wie laut man das raus schreien muss! Die namespaces machen weder docker noch systemd selbst, das sind lediglich Schnittstellen zum Kernel
Sorry, aber wer 2019 noch initscripts benutzt hat sich in die falsche Branche verlaufen
Noch nie gesehen?
ProtectSystem, ProtectHome, ProtectControlGroups, ProtectKernelModules, ReadOnlyPaths, ReadWritePath, InaccessiblePaths, LockPersonality, NoNewPrivileges, PrivateDevices, PrivateTmp, RestrictNamespaces, SystemCallFilter, CapabilityBoundingSet, AmbientCapabilities
Vor allem in Kombination mit PermissionsStartOnly kannst du damit in ExecStartPre und ExecStopPost mit vollem root Rechten agieren und den eigentlichen Dienst trotzdem maximal einschränken
Einfach mal RTFM und in 2019 ankommen bevor es vorbei ist
Und ja auch du hast in deinem ersten Post von "Sicherheitslücken schwerer auszunutzen" gesprochen während das Gegenteil wahr ist, die scheiss container sind üblicherweise mies gepflegt was enthaltene libraries betrifft und inflationär eingesetzt ist das ein horror
Aber nachdem du wie du sagtest ja eh kein admin bist wozu erzähle ich das einem "devops" der ohne container keine testumgebungen aufzusetzen im stande ist
Pflege von containern ist viel einfacher. Dass man sie - wie alles andere - auch pflegen muss wer hätte das gedacht!
Du musst schon die Container benutzen, die passen. Also für einen Server nicht die Entwicklercontainer nehmen. Und wenn du noch höhere Ansprüche hast, dir z.B. ein Alpine Linux nicht genügt, ja mein Gott - dann beginnst du halt "FROM scratch", machst weiter mit "ADD Verfluchtnochmal_5987108.tgz".
Trotzdem bleibt das getestete Software in einer minimalen Umgebung - normalerweise direkt vom Open Source Projekt konfiguriert und paketiert. Ohne Seiteneffekte, die deine Konfiguration zerlegen könnten. Mit nur den absolut notwendigen Schnittstellen nach draußen. Und das System kannst du auf deiner Hardware dann auch gleich mehrfach und trotzdem getrennt laufen lassen.
Weil du aber alles besser weißt und neben deinem abstoßenden Namen hier auch noch alle möglichen Leute durchbeleidigst (heute bin ich es wohl), werde ich ab jetzt nicht mehr auf auf deine scheinbar tiefsinnigen Posts antworten.
Ich bleibe dabei "Sicherheitslücken sind schwerer auszunutzen", es sei denn, du compilierst und paketierst alles selbst - und zwar anders als die Distributionen (damit Standard-Exploits möglichst nicht mehr durchlaufen). Aber das kannst du auch mit Containern machen. Siehe oben. Du splittest dein System halt auf, wenn auf einer Maschine unterschiedliche Dienste laufen.
Und gleich nochmal - ich habe nie behauptet, dass das der einzige Weg ist, Dienste zu isolieren. Und ich habe nie behauptet, dass das immer sinnvoll ist. Es ist aber praktisch mit den in sich getesteten Softwareeinheiten, die nun problemlos in Größe und Funktion kombiniert werden können und die Container werden auch nicht mehr verschwinden.
Zur Isolation verwendet man VM's, die werden auch nicht verschwinden und ja ich baue software für Dienste die im Netz hängen selbst so optimiert und gehärtet wie nur möglich plus alles was systemd an Sicherheitsoptionen hergibt und schreiben run wir die darauf laufende Software auch seit ich denken kann selbst, heute nennt man das wohl DevSecOps
Auf'm AFN gab's in meiner Jugend einen (nichtkommerziellen) Werbespot, in dem eine Horde Betrunkener ein Lied grölte, das man kaum erkennen konnte.
Aus dem OFF kam dann eine Stimme: "They think they can sing. They also think they can drive. Don't drink and drive!"