Linux 2.6.8

[fluid]

Ich habe eine neue Konfigurationsoption bemerkt, die eine Default-Codepage für FAT-Dateisysteme angibt. Allerdings muss man dann auch die Codepages mitkompilieren, weil sich FAT-FS (wie z.B. SD-Karten) sonst nicht mehr mounten lassen.

[peschmae]

apropos, was ist denn nun mit Suspend? und dem Bootlogo? ist wahrscheinlich immer noch nicht drinn.. oder ??

Suspend? Ist immer noch drinne. Software Suspend 2 aber nicht - das dauer noch ne Weile.
PM_DISK scheint bald entfernt zu werden - aus dem MM-Tree ists jedenfalls schon rausgeflogen.

MfG Peschmä

[sebas]

Wichtige Teile von pmdisk sind in 2.6.8-rcX-mmY in swsusp(1) gemerged. Wenn sich der Sturm da etwas gelegt hat, wird angefangen software suspend 2 zu mergen. Es sind auch noch einige Treiberfixes unterwegs, und der PPC port fuer software suspend 2. Wenn das soweit ist, kommt wahrscheinlich der support fuer X86-64.

[der_schreiner]

Hat jemand von euch seit 2.6.8.1 eine CD gebrannt?

Geht nicht, weder normal noch mit SCSI Emulation

Solltet ihr mal testen, 2 grosser Fehler nach dem NFS

Könnte ein 2.6.8.2 geben ....

[fred19726]

Hat jemand von euch seit 2.6.8.1 eine CD gebrannt?

Geht nicht, weder normal noch mit SCSI Emulation

Solltet ihr mal testen, 2 grosser Fehler nach dem NFS

Könnte ein 2.6.8.2 geben ....

Hier ein Link auf die Linux Kernel Mailingliste incl. Patch für das CD Brenn Problem

[weizenbier]

Hallo der_schreiner,

also bei mir geht Brennen ohne Probleme. Habe ein Plextor 24/10/40 A Laufwerk.
Alles ohne den Patch des Vorposters.

Ciao,

Weizenbier

[KBDCALLS]

Hat jemand von euch seit 2.6.8.1 eine CD gebrannt?

Geht nicht, weder normal noch mit SCSI Emulation

Solltet ihr mal testen, 2 grosser Fehler nach dem NFS

Könnte ein 2.6.8.2 geben ....

Hier ein Link auf die Linux Kernel Mailingliste incl. Patch für das CD Brenn Problem

Heißt wohl Finger davon.

[der_schreiner]

@fred19726: Danke vielmals!!

Eine Zeile Code auskommentieren und fertig!!

Wenn nur alles so einfach wäre

[julien]

Hat jemand von euch seit 2.6.8.1 eine CD gebrannt?

Geht nicht, weder normal noch mit SCSI Emulation

Solltet ihr mal testen, 2 grosser Fehler nach dem NFS

Könnte ein 2.6.8.2 geben ....

Hier ein Link auf die Linux Kernel Mailingliste incl. Patch für das CD Brenn Problem

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

[pdreker]

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.

<torvalds@ppc970.osdl.org>
Be a bit more anal about allowing SCSI commands to be sent.

Normal users shouldn't have access to the raw device anyway
unless they are in the trusted "disk" group, but let's require
RAWIO capabilities. That's what the original SCSI interfaces
did anyhoo.

We probably _should_ just require write access, but that will
need more of a code change to pass down the file descriptor.

Die Tabelle mit den erlaubten Befehlen wird aktuell noch ausgearbeitet, bis dahin geht Sicherheit vor Bequemlichkeit.

Als root geht cdrecord und auch growisofs.

Patrick

[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.