Linux 2.6.8

[KBDCALLS]

Ich weiß auch überhaupt net was das soll. Brennen is doch klar ne Aufgabe die man als Benutzer machen will, oder etwa nicht? Wieso wird das also dann für die normalen Benutzer verboten? Ich verstehs net.

Naja spiel ich den Patch mal ein und dann schon wieder kompillieren

Ohne diese Änderung, ist es jedem, der CDs brennen kann möglich, z.B> die Firmware des Laufwerks zu löschen, und es damit endgültig in Schrott zu verwandeln. Diese Sicherheitslücke wurde gestopft.



Patrick

Ist das denn schon mal irgendwo passiert? Gibt es dafür Beispiele / Belege ?

[tylerD]

Ist das denn schon mal irgendwo passiert? Gibt es dafür Beispiele / Belege ?

Es ist theoretisch möglich. Also ein potentielles Sicherheitsloch welches gestopft werden muss.

Muss eine Lücke immer erst ausgenutz werden um sie zu schließen?

cu

[der_schreiner]

Muss eine Lücke immer erst ausgenutz werden um sie zu schließen?

Die Frage ist, ob das als Sicherheitslücke angeschaut werden muss. Denn ich denke das kein User, der an einen Rechner geht sich mal denkt da müsste ein Firmware Update hin.

PS: unter jedem anderen OS ist es auch möglich den Brenner oder auch andere Hardware durch eine Firmware zu zerstören. Ich denke man sollte den "Sicherheitswahn" nicht übertreiben. Denn wie sicher ist es wenn ich meiner Mutter mein Root PW geben muss nur, damit sie eine CD brennt? Ich meine rm -rf / ist schneller eigegeben, als ein Laufwerk zerstört....

[tylerD]

Die Frage ist, ob das als Sicherheitslücke angeschaut werden muss. Denn ich denke das kein User, der an einen Rechner geht sich mal denkt da müsste ein Firmware Update hin.

Denkt sich das kleine Programm(manchmal auch Virus genannt) was durch eine andere Sicherheitslücke in einem Anwendungsprogramm im Kontext des Benutzers der dummerweise Rechte zum brennen hat das auch?

PS: unter jedem anderen OS ist es auch möglich den Brenner oder auch andere Hardware durch eine Firmware zu zerstören. Ich denke man sollte den "Sicherheitswahn" nicht übertreiben. Denn wie sicher ist es wenn ich meiner Mutter mein Root PW geben muss nur, damit sie eine CD brennt? Ich meine rm -rf / ist schneller eigegeben, als ein Laufwerk zerstört....

Es ist ein Fehler, er wurde gefunden und gefixt. Fertig. Keine Problem mehr damit.

Nun ist es an den Kernelentwicklern und/oder Anwendungsentwickler das neue "Feature" so zu benutzen, dass alle Funktionalität wieder funktioniert.

Es ist OS. Jedem steht frei, das Risiko für sich selber festzulegen und den Kernel zu patchen oder bis das "Problem" behoben ist einen älteren zu verwenden.

Und wenn wir bei der Diskussion sind, wer definiert denn welches Sicherheitsloch unkritisch ist und bloß Sicherheitswahn ist? Erzählst du es demjenigen dann der sich einen neuen Brenner kaufen kann, weil sein alter zerschossen wurde (vielleicht sogar nur durch ein fehlerhaftes Programm).

cu

[porci]

Also, ich weiß ja nun nicht genau, was da mit dem 2.8er Kernel ist, aber ich finde, dass du in einigen Punkten nicht unbedingt Recht hast.

Denkt sich das kleine Programm(manchmal auch Virus genannt) was durch eine andere Sicherheitslücke in einem Anwendungsprogramm im Kontext des Benutzers der dummerweise Rechte zum brennen hat das auch?

Dafür gibt es Rechteverteilung unter Linux. Wenn ich eine Gruppe habe, die den Brenner benutzen kann, dann kann nur diese Gruppe den Brenner verwalten. Falls der Brenner plötzlich eine defekte Firmware haben sollte, weiß ich, wo ich suchen kann.

Es ist ein Fehler, er wurde gefunden und gefixt. Fertig. Keine Problem mehr damit.

Es ist kein Fehler! Ein Fehler ist etwas anderes. Wenn ich nicht mehr brennen könnte, weil eine Zeile Code falsch ist, dann wäre das ein Fehler. Wenn ich die Firmware flashen kann, weil ich die Rechte dazu habe, ist das kein Bug. Evt. ein Designproblem, aber definitiv kein Bug!

Nun ist es an den Kernelentwicklern und/oder Anwendungsentwickler das neue "Feature" so zu benutzen, dass alle Funktionalität wieder funktioniert.

Es wäre aber nett, wenn solche Dinge vorher bekannt gemacht werden. Das Changelog reicht dafür nicht aus, denn das ist verdammt groß!!! Außerdem ist es nicht nett, wenn ständig gravierende Änderungen durchgeführt werden, die andere Entwickler dazu zwingen, immer wieder ihre Software zu aktualisieren.

Und wenn wir bei der Diskussion sind, wer definiert denn welches Sicherheitsloch unkritisch ist und bloß Sicherheitswahn ist? Erzählst du es demjenigen dann der sich einen neuen Brenner kaufen kann, weil sein alter zerschossen wurde (vielleicht sogar nur durch ein fehlerhaftes Programm).

Sicherheitslücken werden ständig eingestuft. Selbst Debian macht so etwas. Das muss sein, denn du musst dich entscheiden, was du zu erst behebst. Soviele Resourcen gibt es nämlich nicht, um alle Lücken sofort zu beheben (das wäre dann wohl auch das Paradies).
Außerdem kann man bei einem Brenner die Firmware immer wieder überschreiben. Es ist ein Flash-ROM. Und ein Brenner ist nicht überlebenswichtig für das System

[peschmae]

Also, ich weiß ja nun nicht genau, was da mit dem 2.8er Kernel ist, aber ich finde, dass du in einigen Punkten nicht unbedingt Recht hast.

2.6.8

Dafür gibt es Rechteverteilung unter Linux. Wenn ich eine Gruppe habe, die den Brenner benutzen kann, dann kann nur diese Gruppe den Brenner verwalten. Falls der Brenner plötzlich eine defekte Firmware haben sollte, weiß ich, wo ich suchen kann.

Das meinst du doch nicht ernst, oder? Du hast also nix dagegen wenn jeder Benutzer der brennen darf auch eben mal die Firmware überschreiben und damit das Laufwerk zerstören kann?

Es ist kein Fehler! Ein Fehler ist etwas anderes. Wenn ich nicht mehr brennen könnte, weil eine Zeile Code falsch ist, dann wäre das ein Fehler. Wenn ich die Firmware flashen kann, weil ich die Rechte dazu habe, ist das kein Bug. Evt. ein Designproblem, aber definitiv kein Bug!

Doch sicher ist das als Bug zu behandeln. Wenn du jemandem Rechte an der Brennerdevice gibst dann mit der intention dass er brennen kann und nicht damit er da eben mal Flashen kann.

Es wäre aber nett, wenn solche Dinge vorher bekannt gemacht werden. Das Changelog reicht dafür nicht aus, denn das ist verdammt groß!!! Außerdem ist es nicht nett, wenn ständig gravierende Änderungen durchgeführt werden, die andere Entwickler dazu zwingen, immer wieder ihre Software zu aktualisieren.

Ich denke mal die Entwickler der Apps die das betrifft wurden da schon entsprechend informiert (sind ja nicht soo viele - Hauptsache cdrecord u. cdrdao)
Bugs sind nie nett. Aber mir ist es lieber er ist behoben sobald bekannt als dass man ihn n bisschen länger drinlässt weils bequemer für den Endanwender wäre. Am besten gar nix mehr ändern, 2.6 ist ja stable...

Außerdem kann man bei einem Brenner die Firmware immer wieder überschreiben. Es ist ein Flash-ROM. Und ein Brenner ist nicht überlebenswichtig für das System

Natürlich nicht überlebenswichtig. Aber billig sind die Dinger auch nicht gerade.
Und wenn da (absichtlich oder nicht) keine richtige Firmware draufgespielt wurde sondern falsche/defekte/garnix dann ist ein Firmwareupgrade nicht mehr ganz so einfach wie auch schon. Im schlimmsten Fall trittst du das Teil definitiv in die Tonne.

MfG Peschmä

[porci]

Das meinst du doch nicht ernst, oder? Du hast also nix dagegen wenn jeder Benutzer der brennen darf auch eben mal die Firmware überschreiben und damit das Laufwerk zerstören kann?

Natürlich meine ich das Ernst. Entweder habe ich Zugriff auf den Brenner oder nicht. Es ist ein Gerät. Wenn man es sicher haben möchte, müsste es zwei Devices geben, eins zum Brennen und eins zum Flashen. Das ist aber nicht so gelöst worden. Wenn ich anfange irgendwo anders im System neue Sicherheitsfeatures zu implementieren, wird doch das ganze System unlogisch. Wozu brauche ich denn dann noch eine Rechteverwaltung über Benutzer, wenn das eh der Kernel macht?
Wenn ich eh auf dem Rechner brennen kann, werde ich wahrscheinlich auch physikalischen Zugriff haben. Dann kann ich auch gleich das Bios des Rechners kaputt hacken...
Naja, anscheinend ist der 2.6.8er ja insgesamt nicht so der große Wurf geworden. Schade eigentlich, dass die Qualität beim Kernel wieder nachlässt. Das erinnert mich stark an den einen 2.4er Kernel (11er, 12er ???), der Dateisysteme geschreddert hat.

[Savar]

nur mal so nebenbei.. die Rechteverwaltung liegt ja selbst nach dem Patch noch beim User.. nur bis vor dem Patch konnte man keine vernünftige Rechteverwaltung aufstellen, da es nur GANZ oder GAR NICHT gab.. und das ist definitiv nicht logisch im Linux/Unix bereich.. sonst gäbe es keine RWX sondern bloss ON/OFF bzw. es gäbe keine Gruppen sondern nur User! Dementsprechend gebe ich eher peschmae recht, auch wenn ich es nicht unbedingt ein Bug sondern eine unreife Lösung nennen würde, bei der es notwendig war, diese zu korrigieren und zu verbessern.

So das war dann mal mein Standpunkt

[pdreker]

Natürlich meine ich das Ernst. Entweder habe ich Zugriff auf den Brenner oder nicht. Es ist ein Gerät. Wenn man es sicher haben möchte, müsste es zwei Devices geben, eins zum Brennen und eins zum Flashen.

Lass mich raten: Du weisst nicht, wo das eigentliche Problem liegt, richtig? OK, Kurzversion: Wenn man den Brenner lesend (!) öffnen kann (2.6.7) kann man beliebige SCSI Befehle an das Gerät schicken. Auf diese Art und Weise brennt man auch CDs. Einige dieser Befehle können aber einfach das Gerät dauerhaft plattmachen. Die von Dir angesprochene Trennung ist genau das, was jetzt gerade erfolgt, und zwar nicht mit einer total künstlichen und sinnlosen Trennung von einem Gerät in zwei, sondern per SCSI Befehls Filter. In der aktuellen Version werden alle direkten Befehle verweigert, es sei denn, der User hat CAP_RAWIO, was eigentlich (seit Jahren) die richtige Methode gewesen wäre.

Dieses Gejammer über die nachlassende Kernelqualität ist ja wohl echt unangebracht. Wenn Du die Kernelentwicklung nicht unmittelbar verfolgst, dann warte nach dem Erscheinen eines neue Kernels doch erstmal eine Woche und schaue, ob irgendwelche Probleme gefunden werden. Niemand erwartet, dass Du die LKML liest, aber nach einem Release ein paar Tage zu warten, und z.B. http://kerneltrap.org zu lesen ist echt nicht zu viel erwartet.

Das "Nicht brennen können" einer CD mit Datenkorruption zu vergleichen ist auch total daneben. Abgesehen von der Tatsache, dass der 2.4.11 Kernel nach 2 oder 3 Stunden als 2.4.11-dontuse auf den ftp Servern markiert war, ist wohl niemand wirklich von dem Problem ernsthaft getroffen worden.

Ach ja... die GPL sagt da auch noch was:

Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software.

Patrick

[Hackmeck]

Kernel 2.6.8 ist in unstable.

[schoppi]

Wenn ich eh auf dem Rechner brennen kann, werde ich wahrscheinlich auch physikalischen Zugriff haben. Dann kann ich auch gleich das Bios des Rechners kaputt hacken...

Also ich hab schon des öfteren "remote" gebrannt. Sei es per ssh und cdrecord auf der console oder mit X-Forwarding.

Für die Leute die sich denken: Auf meiner Arbeitsstation hat aber niemand remote Zugriff:

Da gibt es die Leute die nen "Linux-Router-Server" zu Hause haben. Darauf läuft natürlich ein ein xmule/mldonkey und weil der alte CD-Brenner nach dem Kauf vom DVD Brenner überflüssig ist, kommt er natürlich auch in den Server.

Und bevor Ihr jetzt mit IPTables/Firewall anfagt:

Das ist ja kompliziert einzurichten, und wenn ich nen Proxy (squid) hab, ist meine Arbeitsstation auch geschützt.
Selbst wenn iptables eingerichtet sind, werden nach aussen oft Dienste angeboten die relative leicht, weil nicht gepflegt, gehackt werden könnnen.


Wie ich auch in diesem Thread feststelle: die Leute sind zu faul sich mit dem System / der Sicherheit zu beschäftigen. Also muss von vorn herein alles sicher und vor allem Narrensicher sein. Ersteres wird versucht von den Programmierern umzusetzten. Für zweiteres sollte man auf Distris zurückgreifen, die erprobt sind. Und dazu zählen Debian sid und zB Gentoo nicht.

schoppi

[porci]

Lass mich raten: Du weisst nicht, wo das eigentliche Problem liegt, richtig? OK, Kurzversion: Wenn

Das habe ich ja in meinem ersten Post schon geschrieben, dass ich die Probleme nicht genau kenne. Für mich klingt das bis jetzt nur so, dass man mit dem 2.6.8er nur noch als Root brennen kann.
Zu dem Filter: Das ist ja an sich eine gute Sache, aber warum kann ich dann nur noch als Root brennen? Ist das nicht eigentlich sogar unsicherer, denn wenn ein Produktivsystem von mehreren Leuten eingesetzt wird und ich muss die Programme als Root starten, können sich die anderen dann nicht sogar eher zusätzliche Rechte erschleichen? Vorher konnten sie den Brenner zerstören. Natürlich ist das nicht wünschenswert, aber wenn cdrecord jetzt zum Beispiel einen unbekannten Bug hat und jemand den ausnutzt? Na dann ist wohl nicht nur der Brenner im Ar****. Dann habe ich lieber eine Gruppe, die Brennen darf und wenn der Brenner plötzlich nicht mehr laufen würde, dann nehme ich mir alle Benutzer, die zu dieser Gruppe gehören. Einer von denen muss es dann ja gewesen sein.

Dieses Gejammer über die nachlassende Kernelqualität ist ja wohl echt unangebracht. Wenn Du die Kernelentwicklung nicht unmittelbar verfolgst, dann warte nach dem Erscheinen eines neue Kernels doch erstmal eine Woche und schaue, ob irgendwelche Probleme gefunden werden. Niemand erwartet, dass Du die LKML liest, aber nach einem Release ein paar Tage zu warten, und z.B. http://kerneltrap.org zu lesen ist echt nicht zu viel erwartet.

Ich jammere nicht, ich stelle fest. Erst der NFS-Bug, der ja nun mehr als peinlich ist. Warum merkt niemand solche Fehler? Das beziehe ich nicht nur auf Linux, sondern allgemein auf Software. Jetzt kommt die Sache mit dem Brennen. Da solche, meiner Meinung, gravierenden Änderungen nicht genug hervorgehoben werden, ist es doch klar, dass viele sich den neuen Kernel besorgen, kompilieren und auf die Schnauze fallen. Ich habe angefangen das Changelog zu lesen, habe es aber nach einigen 100 Zeilen aufgegeben. Das Changelog ist wirklich riesig. Außerdem warte ich immer einige Tage ab, bis andere den Kernel für mich getestet haben
Danke für den Link, die Seite werde ich mir mal genauer anschauen und bookmarken.

[Usambara]

Habe ich eben gefunden:

http://www.pro-linux.de/news/2004/7173.html

Usambara

[Joghurt]

Außerdem kann man bei einem Brenner die Firmware immer wieder überschreiben. Es ist ein Flash-ROM. Und ein Brenner ist nicht überlebenswichtig für das System

Aber ohne funktionierende Firmware kannst du nicht auf das CD-ROM zugreifen und ergo auch keine korrekte Firmware einspielen. (Bei mir wurde früher durch einen Plattenfehler anstatt eines neuen BIOS der Windows KERNEL.EXE ins BIOS gebrannt. Da blieb auch nur noch: BIOS raus und von Hand neu Flashen lassen):
Ob man den EEPROM kurz auslöten und neu programmieren kann, weiss ich jetzt nicht.

[KBDCALLS]

Außerdem kann man bei einem Brenner die Firmware immer wieder überschreiben. Es ist ein Flash-ROM. Und ein Brenner ist nicht überlebenswichtig für das System

Aber ohne funktionierende Firmware kannst du nicht auf das CD-ROM zugreifen und ergo auch keine korrekte Firmware einspielen. (Bei mir wurde früher durch einen Plattenfehler anstatt eines neuen BIOS der Windows KERNEL.EXE ins BIOS gebrannt. Da blieb auch nur noch: BIOS raus und von Hand neu Flashen lassen):
Ob man den EEPROM kurz auslöten und neu programmieren kann, weiss ich jetzt nicht.

In der Regel sind die EEPROMS pinkompatibel zu den EPROMS.
Heißt ich kann ein EEPROM durch ein stinknormales EPROM ersetzen.

[LittleBoy]

Zu dem Filter: Das ist ja an sich eine gute Sache, aber warum kann ich dann nur noch als Root brennen?

Das ist ja so nicht richtig: k3b scheint das Gerät im Nur-Lesen Modus zu öffnen, und ein fragwürdiges SCSI CMD (SELECT_MODUS) zu senden.
Mit einem ungepatchten, aktuellen cdrecord scheint bei den meisten das Brennen zu funktionieren.

Man kann den Kernel Entwicklern jetzt vorwerfen, dass man die Anwendungsentwickler nicht früh genug bzw. gar nicht informiert hat, man kann auch sagen, dass ein ChangeLog nicht aussagekräftig genug ist - man kann aber auch sagen, dass niemand dazu gezwungen ist, den 2.6.8.1er Kernel zu benutzen. Der 2.6.7 ordentlich gepatcht läuft auch gut. Witzigerweise erklärt sich hier auch niemand bereit, mal das ChangeLog der aktuellen Kernel anzusehen, die Updates zu beurteilen, und dann hier einen aussagekräftigen Post zu erstellen. OpenSource lebt vom Mitmachen und nicht vom Fordern. Schliesslich muss alles ja auch von jemandem gemacht werden - und mir ist es lieber, wenn sich die Entwickler auf das Programmieren konzentrieren...

Generell war die alte Situation wie hier schon aufgeführt ziemlich bescheiden und hat wohl dazu geführt, dass unsauber programmiert wurde. Mit Sicherheit wird auch noch an dem Filter weiter rumgeschraubt, zumal die praktische Bedeutung einiges SCSI Befehle gar nicht so eindeutig zu sein scheint.

Allerdings verstehe ich nicht den riesen Aufstand, der darum gemacht wird.

[porci]

So wie es scheint, könnten wir evt. bald mit einem 2.6.8.2er Kernel beglückt werden: http://www.pro-linux.de/news/2004/7173.html
Auch wenn ich mit meiner Meinung hier ja anscheinend alleine stehe, aber ich glaube immer noch, dass man vom 2.6.8er lieber die Finger lassen sollte.

[Voyager_MP]

Ich stimme porci, voll zu, immer diese heilige kernel entwickler in den himmel zu tragen ist quatsch,

Ich hab nur probleme mit dem 2.6.8, erst das nfs problem, dann kahm 2.6.8.1 und jetzt klappte nebem dem brennen auch das acpi resume von suspend to ram nicht mehr...

der 2.6.8er ist mist, manchmal muß man die sachen auch beim namen nennen.

ich downgrade wieder zu 2.6.7 und bleib erst mal dabei. In zukunft hab ich aber aus diesem problem gelernt, und werde wirklich erst ein paar wochen wachten bis ich einen neuen kernel compiliere. Obwohl das meiner Meinung nach dem grundgedanken von OPEN SOURCE wiederspricht.
Aber solange die Entwickler nicht wenigsten die dicksten löschen stopfen, gehts wohl nicht anders.

Michel

[C_A]

immer diese heilige kernel entwickler in den himmel zu tragen ist quatsch,
[...]
der 2.6.8er ist mist, manchmal muß man die sachen auch beim namen nennen.

Harte Worte - die ich für unangebracht halte.

[Bert]

ich downgrade wieder zu 2.6.7 und bleib erst mal dabei. In zukunft hab ich aber aus diesem problem gelernt, und werde wirklich erst ein paar wochen wachten bis ich einen neuen kernel compiliere. Obwohl das meiner Meinung nach dem grundgedanken von OPEN SOURCE wiederspricht.

Könntest Du das erläutern? Ich hänge immer mehrere Monate mit meinen Kernel hinterher und will nur ungern gegen Grundgedanken verstoßen

Im ernst: ich versteh die Aussage nicht. Im Sinne von Opensource würdest Du handlen, wenn Du die Quellen nimmst und die Probleme beseitigts. Da nicht jeder (mich inbegriffen) ein Kernelentwickler ist, hab ich ja immer noch die Wahl einen anderen Kernel zu benutzen...

Bert

[chimaera]

'mal zurück zum thema: seit wann muss ich beim mounten von vfat partitionen (memory-stick) das iocharset explizit übergeben? rethorische frage, da seit 2.6.8, aber wieso?

[LittleBoy]

Weil es keine Möglichkeit gibt, das aus dem Filesystem heraus zu erkennen. Bislang wurde halt immer 437 als Standard genommen, was für uns Deutsche kein grösseres Problem darstellt - aber im nicht deutschsprachigen Raum zu Problemen führt.

[chimaera]

hab im kernel 437 als default iocharset angegeben.. kann jemand, so es funktioniert, den entsprechenden bereich posten (nls-codepages)?

[g-henna]

Hi!

Außerdem kann man bei einem Brenner die Firmware immer wieder überschreiben. Es ist ein Flash-ROM. Und ein Brenner ist nicht überlebenswichtig für das System

Aber man kann doch, neben der Unbrauchbarmachung des Brenners, auch richtig böse Sachen damit anstellen, oder? Ich meine, Firmware kontrolliert doch alles, was auf dem Brenner passiert, stimmt's? Kann man dann nicht z.B. die auch so zurechthacken, dass sie an jedes Programm unbemerkt einen bestimmten Codefitzel anhängt, der dann sich irgendwie böse weiterverbreitet mit jeder gebrannten CD?

Bye
g-henna

[Savar]

hmm.. ich denke, damit du es schaffst die Dateien durchzuparsen und ausführbare Dateien aufzufinden und zu kompromitieren könnte der Platz für die Firmware etwas zu klein sein.. aber lass mich gerne eines besseren belehren