| |
 |
| Kernel-Module per Drag'n'Drop installieren |
|
|
Veröffentlicht durch tbf am Samstag 29. Maerz, 19:34
Aus der frauen-und-kinder-zuerst Abteilung
|
|
|
|
|
Arglos bei FootNotes vorbeisurfend, springt mich eine grausige Schlagzeile an; zieht mir die Socken vom Schuh. -- gmodconfig! --
Da hat sich doch tatsächlich jemand hingesetzt, und ein grafisches Tool zum herunterladen, compilieren, installieren und konfigurieren von Kernelmodulen geschrieben.
|
|
|
|
|
|
|
Solch ein Tool schreit natürlich nach einem Audit. Gedacht. Gesaugt. Gelesen.
Zuerst fällt auf: Das Teil ist in C++ geschrieben, 2700 Zeilen, recht ordentlich OOP und kommentiert. Greppen nach "setuid" und Co liefert erstmal nichts, aber eine laxe Einstellung gegenüber Sicherheit, kommt nicht nur bei der Projektfindung, sondern auch beim Umgang mit externen Programmen zum Vorschein: Das Tool "modinfo" wird mitsamt einigen Parametern der Bibliotheksfunktion "popen" übergeben. Ihm Hintergrund werkelt unser aller Freund "system". Gut, zum Teil mag hier die idiotische Haltung einiger gcc-Maintainer bezüglich "ifstream::ifstream(int fd)" schuld tragen. Kritisch ist nur der darauf folgende Kommentar, der explizit "Convinience" als Designkriterium hervorstellt. Etliche Stellen des Codes offenbaren, dass der Programmauthor stark durch Windows geprägt ist -- Dies mag auch Motivation, dieses Tool zu schreiben, sein. Der Code enthält ein paar offensichtliche Bugs ("modules.conf"-Parser, I10N-Handling), scheint aber ansonsten soweit sicher zu sein. Nur beim aktuellen Projektstand verwundert dies kaum: Vom vollmundig angekündigten Funktionsumfang ist bisher nur das Anzeigen von Modul-Informationen (per modinfo und separater XML-Datei) implementiert.
Meine Einstellung zu derartigem Treibern ist aber klar:
Was ist nur aus dem guten alten RT(F)M geworden? Wisst ihr Kinders: Irgendwo hört der Spass auf. Was kommt als nächstes: LKM-Rootkit1) installieren per E-Mail-Client?
1) Linux-Kernel-Modul-Rootkit, das Gegenstück zum Outlook-Wurm
|
|
|
|
< NZZ zum Thema SCO vs. IBM | Druckausgabe | xmms.org gecrackt > | |
|
|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
|
|
|
|
|
Jetzt will ich's aber wissen: was ist mit dieser anspielung gemeint ?
Allgemein: Was an der software so verwerflich sein soll, versteh' ich nicht. Steh' ich hier auf der leitung und das ganze artikel ist ein Aprilscherz ?
Real C programmers never die, they cast to void...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja verstehe ich auch nicht. Linux hat so breit gefaecherte Software, dass es sich praktisch ueberall einsetzen laesst und es praktisch jede Spielerei erlaubt! Wenn dir ein Stueck Software nicht gefaellt dann meckere doch nicht drueber ab. Wenn sich schon jemand die Muehe macht und es von mir aus DAU's benutzen werden soll man von mir aus den Sicherheitskritischen Aspekt beleuchten, aber "mir ziehts fast die Socken aus" find ich echt fehl am platz. Oder hast du das bei KDE, dem 10-tausendsten-nethack-client oder der Familiar Distri (Linux auf IPaq) auch gesagt?
----------------
Wer gegen ein Minimum
Aluminium immun ist, besitzt
Aluminiumminimumimmunität
|
|
|
|
|
|
|
|
|
|
|
|
|
Können wir den Aprilscherz nicht auf Oktober oder so verschieben, dann hätte ich auch etwas mehr Zeit und wäre voll bei der Sache?
NSG
--
"In keinem Bereich menschlicher Leistungen sind so schlechte Ergebnisse erzielt worden wie in der Politik!"
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 29. March, 21:52 MES (#5)
|
|
|
|
|
Ich verstehe auch nicht, was daran so gefährlich sein soll? Solange die Installation nicht automatisch im Hintergrund läuft wie bei Windows-Update sehe ich kein Problem. Oder seht Ihr euch wirklich jeweils 10 Stunden den Quellcode des Moduls durch, bevor ihr es kompiliert? ;-)
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Saturday 29. March, 22:04 MES (#6)
|
|
|
|
|
Dem kann ich mich nur anschliessen, und ich denke wenn meine Mutter es durch so ein Programm schafft die Digicam zum laufen zu bringen, wiso nicht. Derjenige der es nicht mag muss es nicht einsetzen. Je mehr Leute von Windows zu Linux wechseln umso mehr Leute gibt es die Linux aktiv supporten ( Programme schreiben, übersetzen, Icons malen... ) Ich mag auch nicht alles in Bunt und zum Clicken, aber mich zwingt ja auch nicht ( im Gegensatz zu anderen Betriebssystemen ) keiner dazu, Linux ist halt so schön weil man die Wahl hat etwas einzusetzen oder nicht.
Grüsse Eric
|
|
|
|
|
|
|
|
|
|
|
|
|
Dann aber auch bitte nicht rumjammern oder rumtrollen, wenn der erste E-Mailwurm mit integriertem LKM-Rootkit auftaucht.
Ich bin mir halt einfach nicht sicher, ob technisch unversierte Nutzer Linux, nicht mehr schaden denn Nutzen: Sie tragen nicht zu neuem Code bei. Sie zerstören durch ständiges Fordern und Nörgeln die Motivation der Enthusiasten. Sie fördern "Innovationen", die das Sicherheitsniveau von Linux, auf das einer Kirmesschiessbude absenken. Sie sind Anlass für das Entfernen sinnvoller Programmfunktionen ("zu kompliziert"). Sie sind der Distributoren Motivation für unsinnige Major-Release-Schlachten ("Linux Version 9").
Ich weiss einfach nicht. Vielleicht bin ich aber auch nur ungemein egoistisch.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 30. March, 01:08 MES (#10)
|
|
|
|
|
Denke nicht das dieses Programm Würmer / Rootkits unterstützt, wenn überhaupt vielleicht Sachen wie Dialer oder ähnliches.
Der technisch nicht so versierte Nutzer wird damit eh nur die LKM konfigurieren/installieren die seine Distri ( SuSe oÄ ) ihm anbieten, also kein Problem. Das Teil soll ja nicht automatisch funzen, sondern braucht noch ne XML? Datei zu jedem Modul in der drinne steht was es kann. Also dient in erster Linie dazu die Module mit Parametern zu laden.
>Sie tragen nicht zu neuem Code bei. Sie zerstören
>durch ständiges Fordern und Nörgeln die
>Motivation der Enthusiasten.
wenn 20 Leute zu Linux wechseln weil es jetzt einfacher ist. Davon sind 19 Dau's und einer Programmierer lohnt es sich imho schon. Und ich als Freeware & Opensource Coder hab bisher noch nie Nörgeleien sondern nur konstruktive Kritik gehört. Du glaubst ja gar nicht wie sich nen Dau über ein Programm freuen kann.
>Sie fördern "Innovationen", die das
>Sicherheitsniveau von Linux, auf das einer
>Kirmesschiessbude absenken.
Nein, selbst wenn dieses Programm die Sicherheit senken würde, würde es das nur auf dem System tun auf dem es installiert ist. Der Sicherheitsbewusste Anwender installiert es sich eben nicht. Darum gehts ja bei Linux, du brauchst nix installieren was du nicht willst, keiner zwingt dich zu etwas.
>Sie sind Anlass für das Entfernen sinnvoller
>Programmfunktionen ("zu kompliziert").
also meistens gibt es dadurch nur noch einen zweiten, einfacheren Weg das komplizierte zu tun. Ich arbeite mich auch gerne in Programme ein und geh etwas in die Tiefe, aber man hat nicht immer die Zeit das mit jedem Programm zu tun, und da freu ich mich auch wenn etwas intuitiv geht.
>Sie sind der Distributoren Motivation für
>unsinnige Major-Release-Schlachten ("Linux
>Version 9").
Es gibt ein Leben jenseits von SuSe und RedHat. Aber wiso freust du dich nicht? SuSe und RedHat machen Geld, aber stecken auch vieles davon in Linux, und ich wette auch du profitierst von den Entwicklungen.
>Ich weiss einfach nicht. Vielleicht bin ich aber
>auch nur ungemein egoistisch.
Glaub ich nicht, ich glaub du hast nur in dem Bereich Scheuklappen auf :) Freu dich einfach darüber das sich dadurch mehr Leute für das OS deiner Wahl interessieren und vielleicht wenige sich auch aktiv dafür einsetzen. Siehe Behörden, wenn Linux einfacher ( Desktoptechnisch ) zu gestalten ist, werden diese eventuell mehr Linux einsetzen, potentielle Arbeitsplätze für einen wie dich und mich die mehr in die Tiefe des Systems blicken. Wie gesagt, jeder kann unter Linux genau wählen was er einsetzen will und was nicht,...
Grüsse Eric
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Sunday 30. March, 03:53 MES (#11)
|
|
|
|
|
Sie fördern "Innovationen", die das Sicherheitsniveau von Linux, auf das einer Kirmesschiessbude absenken.
vermutlich meinst du hier z.B. Lindows, das normale Users als root arbeiten lässt, was natürlich völliger Blödsinn ist.
Allerdings ist Sicherheit sowieso relativ. Linus hat sich z.B. schon ganz am Anfang und völlig ungezwungen für einen monolithischen Kernel entschieden und das ebenfalls aus Usability-Gründen (mehr Geschwindigkeit, bei wenig Code einfachere Architektur). Eine Microkernel-Architektur (z.B. wie minix) wäre aber einiges sicherer, da ein buggy module nicht gleich den ganzen Kernel zum crashen bringen kann.
Moral: Usuability fordert nun mal Kompromisse
|
|
|
|
|
|
|
|
|
|
|
|
|
Du hast recht - nur: solange wir die Wahl haben zwischen diesen Tools und dem RTFM-und-/bin/sh-Weg, und solange die "komplizierten" Details nicht aus dem Weg geschaffen werden, nur vor den Newbies mit Hilfe von sinnvollen Defaults versteckt werden ist das doch alles kein Problem. Ich finde es zumindest toll, wenn durch solche Aktionen Linux mehr mainstream-fähig wird, denn dies wird mehr Firmen dazu antreiben, ihre Software auf Linux zu portieren , so dass dann auch die Profis eine grössere Softwareauswahl haben (und Auswahl ist doch alles ;-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>Gut, zum Teil mag hier die idiotische Haltung >einiger gcc-Maintainer bezüglich >"ifstream::ifstream(int fd)" schuld tragen.
Die idiotische Haltung bezueglich obigem kommt
hauptsaechlich vom C++Standard-Komittee, der dies wegen Unportabilitaet gekippt hat (so a la: laeuft
nicht auf VMS, IBM 390).
Es gehoert trotzdem eingebaut, da gebe ich Dir
recht.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> Die idiotische Haltung bezueglich obigem kommt
> hauptsaechlich vom C++Standard-Komittee, der dies
> wegen Unportabilitaet gekippt hat (so a la: laeuft
> nicht auf VMS, IBM 390).
>
> Es gehoert trotzdem eingebaut, da gebe ich Dir
> recht.
Besonders angesichts der Alternative, die das C++-Standard-Komittee anbietet: FILE-Pointer übergeben. Jungs: Der Ctor mit dem Filedeskriptor wurde nie benutzt, um auf Dateien zuzugreifen. Der Ctor diente dem C++-konformen Zugriff auf Netzwerksockets und Pipes! Zwei essentielle Unix-Konzepte, für die das Standard-Komittee ja immer noch kein vernünftiges API anbietet...
Gut, natürlich gibt's die ANSI-C-Funktion fdopen. Und irgendeine krude Funktion existiert auch, um den Schreibpuffer der gepufferten I/O-Streams (aka FILE) abzuschalten. Nur der Code, der hierbei entsteht ist einfach nicht mehr ansehnlich.
|
|
|
|
|
|
|
|
|
|
|
|
|
Das ist überhaupt nichts neues, BeOS konnte das schon lange, nur die betreffende Datei in einen Ordner kopieren und schon läuft die Hardware. Auch wenn ich persönlich ein Anhänger von RTFM bin, finde ich es doch gut, dass es endlich solche Anstrengungen gibt (für den Durchschnittsuser ist es nämlich zu schwer, Software zu installieren (ja, README lesen und ./configure; make; make install ; echo name >> /etc/modules oder ähnlich ist schon recht anspruchsvoll))
Ich hoffe, dass es aber trotz allem nicht die Sicherheit von GNU/Linux untergräbt...
|
|
|
|
|
|
