Das System mit debsecan härten.

[DeletedUserReAsG]

Hmm … man erklärt dir, warum deine Idee vielleicht doch nicht so gut ist (vollkommen sachlich), du ignorierst es und beschwerst dich stattdessen über die vernünftigen Umgangsformen hier (unsachlich, bzgl. Topic), woraufhin das aufgegriffen wird und du dich anschließend über die Unsachlichkeit beschwerst. Weißt du eigentlich, worauf du hinauswillst?

Ich glaube, du kannst nicht (das Topic betreffend).

[letzter3]

Ohhh, ich kann den Debianator gut verstehen.
Insbesondere der Radfahrer ist gut darin, zu kritisieren, gibt aber aber kaum (ausser Allgmeinplätzen) Hinweise zum Richtigmachen.
Und nein: Radfahrer, ich werde auf keinen deiner folgenden substanzlosen Beiträge reagieren.
Ich lese seit Jahren hier mit, aber das ist wirklich nervig.
Egal, Hauptsache die Beitragszahlen hochschrauben....
Bitte diesen Beitrag auch nur unter dieser Prämisse lesen und sich jeden weiteren nicht zielführenden Kommentar ersparen.
(Das wäre wirklich nett und sinnvoll.....)

[DeletedUserReAsG]

… und ich kann den Radfahrer wiederum verstehen. Genug Leute eröffnen hier Threads mit sinngemäß „Ich hab das Tutorial genau befolgt, und es tut nicht!“, oder es wurde dadurch das System unrettbar zerschossen, möglicherweise auch Daten ruiniert. Schaut man sich dann das „Tutorial“ an, ist’s oft genug ein Text im Stil des Eingangsposts: Jemand hat sich was ausgedacht, was aus seiner Sicht eine gute Idee zu sein scheint und bei ihm auch problemlos funktioniert. Dabei ist der Text so formuliert, als wüsste derjenige, was er da vorschlägt, übersieht da aber die eine oder andere Sache, die zu Problemen führen kann – meist aus Unkenntnis.

Im Gegensatz zu den Texten „da draußen“ gibt es hier die Möglichkeit, auf die Missstände hinzuweisen, und wenn auf die Hinweise dann „Ihr macht das ja nur, um euch zu profilieren!“ kommt, statt auf die genannten Zusammenhänge und Details einzugehen (und wenn, dann relativierend á la „ist ja nicht schlimm, hat ja bei mir funktioniert“), dann kann das schon mal ’ne direkte Antwort darauf, also ohne Sachbezug, zur Folge haben. Warum auch nicht? Etwas nicht zu wissen, ist kein Drama. Das fängt erst an, wenn klar wird, dass derjenige auch gar nicht lernen will (weil’s ja Zeit kostet) und stattdessen sachlich falschen Kram weiterhin so zum Besten gibt, als wüsste er, was er da schreibt. Radfahrer provoziert gerne, ja. Manchmal auch hart am Thema im Threadtitel vorbei, doch meist eben nicht ganz weit ab von dem eigentlichen Problem.

Der sachliche Teil dieses Beitrags: Sid ist der Junge, der immer alles kaputt macht. Der Name wurde bewusst für Unstable gewählt. Holt man sich Pakete aus Sid in sein Stable, ohne sehr genau zu wissen, was man tut, besteht eine hohe Wahrscheinlichkeit, dass Sid das Stable früher oder später kaputtmacht. Abgesehen davon hat das empfohlene Vorgehen, das Unstable-Repo anschließend wieder zu deaktivieren, zur Folge, dass das betreffende Paket fortan festgenagelt ist. Bedeutet: später bei der Version erkannte Sicherheitslücken bleiben auf dem System bestehen, selbst wenn die originalen Stable-Pakete schon längst gefixed sind. Mit Pinning kann man dafür sorgen, dass man die jeweils neue Version aus Sid bekommt – das geht aber eben nur solange gut, wie die Abhängigkeiten von den in Stable vorhandenen Paketen bedient werden. Entweder ist‘s dann wieder festgenagelt, oder man geht auf das Paket aus Stable zurück – und steht dann vor der Ausgangssituation, sobald wieder ein Problem gefunden wird. Zudem kann es passieren, dass das Sid-Paket reverse Abhängigkeiten zerlegt: programm.deb braucht libblub.deb in >=2.0 – die Abhängigkeit würde von libblub.deb in Version 3.0 aus Unstable ja erfüllt, nur leider hat sich der Autor der Lib entschlossen, einige Sachen komplett anders zu gestalten oder Funktionen wegzulassen → programm.deb ist kaputt, obwohl im Paketmanagement keine Fehler auszumachen sind.

debsecan ist sicher kein schlechtes oder nutzloses Script, man kann es durchaus zum Prüfen seines Systems auf problematische Pakete hin hernehmen, aber man sollte definitiv nicht beigehen und die angezeigten Pakete durch welche aus Unstable ersetzen. Vielmehr sollte man sich die Mühe machen und im Securitytracker schauen, wo genau das Problem liegt. Und dann individuell entscheiden, was zu tun ist. Nicht jedes Problem betrifft einen, oft kommen sie nur unter bestimmten Umständen zum Tragen, manchmal ist’s eine kleine Änderung der Config, die das Problem bis zum Update behebt, manchmal kann man auf das Paket verzichten oder auf eine Alternative ausweichen. Und wenn man sich nach sorgfältiger Abwägung der Risiken, Anforderungen und eigenen Kenntnisse dazu entschließt, dass ein Ersatz aus Sid alternativlos ist, sollte man die Entwicklung des Paketes sehr genau im Auge behalten und sobald das gepatchte Paket für Stable verfügbar ist, dieses auch wieder installieren.

Kritik/Korrekturen zum sachlichen Teil sind ausdrücklich erwünscht.


So. Ob das den Threadstarter nun dazu bewegt, seinem Eingangsbeitrag nun den Hinweis voranzustellen, dass der geneigte Leser, der via $suchmaschine auf den Thread gestoßen ist, doch bitte die Anleitung nicht einfach so befolgen, sondern lieber auch die Diskussion dazu lesen sollte?

[dufty2]

Sehr schön erklärt niemand

Ein Beispiel aus der Praxis:

Code: Alles auswählen

grep -i high my_scan
CVE-2015-6581 libopenjp2-7 (remotely exploitable, high urgency)

So, und was hab' ich nun davon, wenn ich jetzt das unstable-paket statt dem testing nehme?
Gar nichts, denn es ist das gleiche und hat demnach auch die gleiche Schwachstelle.
Ähnlich sieht es mit den linux-images aus, z. B.
CVE-2010-5321 linux-image-4.2.0-1-amd64
Die gehen nicht so schnell weg, soll ich jetzt kein Linux(-image) mehr benutzen?

Ab und zu lasse ich
/usr/bin/check-support-status (aus dem Paket 'debian-security-support')
laufen, das hat dazu geführt (war nicht der einzige Grund), dass ich kein KDE mehr benutze.

[KBDCALLS]

Im Grunde genommen ist doch die Diskussion eigentlich müssig. Stable und Sid passen nicht zusammen. Aber wenns unbedingt sein muß

• Securing Debian Manual
• Hardening

[4A4B]

Ich hatte überlesen, dass debiator die Pakete aus Unstable nach Debian stable installieren möchte. Das ist natürlich nicht ratsam. Mein erklärender Beitrag zum Pinning weiter oben bezog sich auf Debian Testing (ich habe den zur Klarstellung jetzt auch nochmal editiert). Bei einigen wenigen Paketen wie Iceweasel oder Chromium installier ich mir bei einem Sicherheits-Update das Paket aus Unstable, um nicht ein, zwei Wochen darauf warten zu müssen.

[AndreK]

ich sehe das relativ locker.
Es sind hier keine mords Ratschläge.
Ich probiere dies und das bei halbwegs gesundem Menschenverstand aus und bei Erfolg will ich Dinge teilen.
Die Profis hier, sind ja auch dazu da, um auf Fehler etc. hinzuweisen.
Ja, die Formulierung ist vielleicht etwas unglücklich gewählt.

Ob sid DER Begriff für unstable ist, ist jetzt inhaltlich füßr das Thema nicht so entscheidend.
Aber danke für die Info, allgemein ist es natürlich gut zu wissen.

Nur mal kurz zum Thema Grundlagen, da das Thema auf allen Gebieten sehr brizantes und fragiles Thema ist.
Ich habe da eine andere Herangehensweise an Lernprozesse. So zwecks "erstmal Grundlagen lernen".
Wenn ich bei allem die bis in die Unendlichkeit sich ausdehenden Grundlagen lernen würde, bevor ich manche Dinge als ein "Zwischenbericht" zur Kommunikation stelle. Wäre ich vielleicht ein unglaublich guter Profi in einem Bereich. Das ist aber nicht mein Ziel. Mein Ziel ist Allgemeinbildung. Da kann man vor allem durch Erklärungen am meisten lernen (das kennt man ja bereits aus Präsentationen, an denen man selbst sehr viel lernen kann).

Ich sehe bis jetzt weniger Probleme in sudo, als im icedove. Totale Fixierung ist nicht vorhanden.
Auch habe ich nirgendwo geschrieben, dass DAS die Härtung schlechthin ist. Systemhärtung betrifft sehr viele Bereiche.... und so weiter.
Dieses Thema endet mehr im Egogetue und Unterstellungen als in Sachlichkeit.

Sachlich gehts darum, dass man aus den unstable-Quellen per Hand ausgewählte Pakete aktualisieren kann, die bei unstable bereits gefixed sind.
Danach nimmt man die Quellen wieder raus. Oder, ja, das wusste ich nicht (wie schrecklich), man kann es viel geschickter mit apt-pinning machen und die unstable Quellen belassen.
Wenn ihr das nicht machen wollt. Ja bitte, ist doch kein Problem.

Diejenigen, die auf irgendeinem Gebiet halbwegs Profis sind, nehmen die Dinge viel zu ernst
Alles paletti!

Diese Profis würden aber niemals ein Linux zu dem Zweck verwenden, das Du anstrebst. Die nehmen die Sache nämlich wirklich ernst.