Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 28.03.06 18:05:45, Claus Malter wrote: > Andreas Pakulat wrote: > >On 28.03.06 16:41:39, Richard Mittendorfer wrote: > >>Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Tue, 28 Mar 2006 15:08:57 > >>+0200): > >>>On 28.03.06 14:50:48, Richard Mittendorfer wrote: > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 21:25:25 > +0200): > [...] > >>>Du gibst im Normalfall dein Passwort ein! Wenn das jemand mitliest kommt > >>>er zumindestens schon an allerlei Informationen. > >>Klar, aber er kann IMHO keine Ueberweisungen damit machen. Die TAN > >>(oder wie immer das heisst) ist IMHO nur fuer eine Transaktion oder > >>Sitzung gueltig? > >Die TAN entspricht deiner Unterschrift auf einem "analogen" > >Ueberweisungstraeger. Und ja, die TAN ist nach einmaligem Gebrauch > >ungueltig. > > In der Zeitung (SZ war es glaub ich) stand vor einiger Zeit, dass ein Hacker > sich in eine solche Sitzung mit der Bank eingeschleust hat. Quasi > "Man-in-the-middle". Nun, dann wurde die Datenuebertragung nicht ausreichend abgesichert. Wenn die Bank nur einen 56Bit Schluessel fürs SSL verwendet ist das natuerlich kein Wunder... > Also in einem solchen Extremfall wäre dann sogar das TAN-System hinfällig. IMHO nicht, das TAN-System hat ja wohl funktioniert. Wenn jemand die Uebermittlung der Ueberweisung abfaengt und seine eigenen Daten eintraegt dann ist das noch kein Beweis dafuer das das TAN-System nicht funktioniert. Erst wenn du zeigen kannst wie du mit einer Menge von abgehoerten TANs die naechstfolgenden berechnen kannst hat das System ein Problem. Oder wenn man eine TAN ein zweites Mal benutzen kann. Andreas -- You will be awarded some great honor. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Andreas Pakulat wrote: On 28.03.06 16:41:39, Richard Mittendorfer wrote: Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Tue, 28 Mar 2006 15:08:57 +0200): On 28.03.06 14:50:48, Richard Mittendorfer wrote: Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 21:25:25 +0200): [...] Du gibst im Normalfall dein Passwort ein! Wenn das jemand mitliest kommt er zumindestens schon an allerlei Informationen. Klar, aber er kann IMHO keine Ueberweisungen damit machen. Die TAN (oder wie immer das heisst) ist IMHO nur fuer eine Transaktion oder Sitzung gueltig? Die TAN entspricht deiner Unterschrift auf einem "analogen" Ueberweisungstraeger. Und ja, die TAN ist nach einmaligem Gebrauch ungueltig. In der Zeitung (SZ war es glaub ich) stand vor einiger Zeit, dass ein Hacker sich in eine solche Sitzung mit der Bank eingeschleust hat. Quasi "Man-in-the-middle". Er konnte dann die TAN abfangen, die Überweisung mit seinen eigenen Daten ausfüllen und das Geld ging dann ganz wo anders hin. Also in einem solchen Extremfall wäre dann sogar das TAN-System hinfällig. [...] Andreas Claus -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 28.03.06 16:41:39, Richard Mittendorfer wrote: > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Tue, 28 Mar 2006 15:08:57 > +0200): > > On 28.03.06 14:50:48, Richard Mittendorfer wrote: > > > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 21:25:25 > > > +0200): > > > > Nee, mit Sicherheit meint er paranoia. Es geht ja um die installierbaren > > > > Extensions. Das sind Programme und die duerfen demzufolge alles was sie > > > > wollen, inkl. die Tastendruecke die du innerhalb von FF machst > > > > "aufschreiben" und irgendwohin schicken. Eventuell haben die sogar > > > > Zugriff auf X11, dann koennen sie _alle_ Tastatureingaben mitloggen. > > > > > > Fragt sich nur, ob das im Onlinebanking mit den fuer eine Sitzung > > > geltenden Codes ein hohes Risiko darstellt. > > > > Du gibst im Normalfall dein Passwort ein! Wenn das jemand mitliest kommt > > er zumindestens schon an allerlei Informationen. > > Klar, aber er kann IMHO keine Ueberweisungen damit machen. Die TAN > (oder wie immer das heisst) ist IMHO nur fuer eine Transaktion oder > Sitzung gueltig? Die TAN entspricht deiner Unterschrift auf einem "analogen" Ueberweisungstraeger. Und ja, die TAN ist nach einmaligem Gebrauch ungueltig. > > Webprogrammierung hat damit eigentlich wenig zu tun. Wenn eine > > FF-Extension alle Key-Eingaben mitloggt dann ist das schon ausreichend. > > Irgendwie muss doch die Kommunkation laufen. Daher der Term > "Webprogrammierung", mir faellt nunmal kein besserer Begriff ein: Webprogrammierung ist das IMHO falsch. Kommunikation mit Banken in Dtl. laeuft i.A. entweder ueber ein https-Verschluesseltes Webinterface, Java-Applet oder besser mit einem Client der HBCI kann. Allen 3en gemein ist das sie HTTP als Protokoll verwendenen. > Aber da ist eine generelles "Problem" mit dem Protokoll im > Web(browser). Ein fuer Onlinebanking eigenes Tool halte ich da fuer > sinnvoller, da es weniger Angriffspunkte bietet. Wer ein Webfrontend ohne Verschluesselung nutzt ist selbst schuld. Ansonsten laeuft auch die Kommunikation beim "eigenen Tool" meistens ueber HBCI und damit ueber HTTP ab. Egal ob nun Pin/Tan oder ein Keycard genutzt wird. > Natuerlich ist hier der Anbieter (die Bank) gefragt, und fuer diese > wieder ist eine nicht-mainstream Plattform wie Linux (in _diesem_ > Bereich) scheinbar wenig interessant. Zumindest hier in AT bieten > Banken sowas fuer das Evil OS[tm] an, ob es auch fuer Linux sowas > gibt weiss ich als Barzahler nicht. Also soweit ich die Architektur von aqbanking (rein Verzeichnistechnisch) verstehe gibts da mehr als nur Unterstuetzung fuers HBCI Protokoll. Unter anderem lese ich hier sowas wie OFX, YellowNet und DTAUS... > Ein keylogger spielt zweifellos in einer Dimension darueber. Egal, ob > er nun als Extension des FF agiert, als Kernelmodul eingebunden wurde > oder sonstwie im System klebt. Wirklichen Schaden kann er erst > anrichten, wenn seine Ergebnisse einsehbar sind. Lokal oder uebers > Netz. Wobei eine FF Extension ja wohl recht leicht Daten uebers Netz transferieren kann... Andreas -- Good day to let down old friends who need help. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Tue, 28 Mar 2006 15:08:57 +0200): > On 28.03.06 14:50:48, Richard Mittendorfer wrote: > > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 21:25:25 > > +0200): > > > Nee, mit Sicherheit meint er paranoia. Es geht ja um die installierbaren > > > Extensions. Das sind Programme und die duerfen demzufolge alles was sie > > > wollen, inkl. die Tastendruecke die du innerhalb von FF machst > > > "aufschreiben" und irgendwohin schicken. Eventuell haben die sogar > > > Zugriff auf X11, dann koennen sie _alle_ Tastatureingaben mitloggen. > > > > Fragt sich nur, ob das im Onlinebanking mit den fuer eine Sitzung > > geltenden Codes ein hohes Risiko darstellt. > > Du gibst im Normalfall dein Passwort ein! Wenn das jemand mitliest kommt > er zumindestens schon an allerlei Informationen. Klar, aber er kann IMHO keine Ueberweisungen damit machen. Die TAN (oder wie immer das heisst) ist IMHO nur fuer eine Transaktion oder Sitzung gueltig? Gerade mal ein man in the mittle wuerde davon profitieren und die in einer FF extension unterzubringen.., naja vielleicht. Phishing scheint da die erfolgversprechendere Methode. Kann gut sein, dass nichts hiervon wahr ist, wie gesagt, kenn ich mich damit nicht aus. Das ein Keylogger oder sonstige malware generell nix Gutes kann und ein Sicherheitsproblem darstellt steht wohl nicht zur Diskussion. > > Allerdings tu' ich weder onlinebanking, noch kenn ich mich in diesen > > Bereichen des Webprogrammierens gut genug aus. > > Webprogrammierung hat damit eigentlich wenig zu tun. Wenn eine > FF-Extension alle Key-Eingaben mitloggt dann ist das schon ausreichend. Irgendwie muss doch die Kommunkation laufen. Daher der Term "Webprogrammierung", mir faellt nunmal kein besserer Begriff ein: Mir ist klar, dass mit einem entsprechender Extension jede Eingabe (zumindest mal die im FF) geloggt und damit dann weitere Aktionen gesetzt werden koennten. Da fuehrt natuerlich auch keine (Transport) Verschluesselung herum. Aber da ist eine generelles "Problem" mit dem Protokoll im Web(browser). Ein fuer Onlinebanking eigenes Tool halte ich da fuer sinnvoller, da es weniger Angriffspunkte bietet. Natuerlich ist hier der Anbieter (die Bank) gefragt, und fuer diese wieder ist eine nicht-mainstream Plattform wie Linux (in _diesem_ Bereich) scheinbar wenig interessant. Zumindest hier in AT bieten Banken sowas fuer das Evil OS[tm] an, ob es auch fuer Linux sowas gibt weiss ich als Barzahler nicht. [OT] Ob nun meine sonstigen Eingaben im Netz von google, microsoft oder dem Betreiber der Webseite geloggt und/oder verkauft wird ist mir grossteils, wenn auch nicht vollkommen, egal. Persoenliche und wichtige Informationen haben in einem Browser mit Verbindung ins Internet nichts verloren. Ein keylogger spielt zweifellos in einer Dimension darueber. Egal, ob er nun als Extension des FF agiert, als Kernelmodul eingebunden wurde oder sonstwie im System klebt. Wirklichen Schaden kann er erst anrichten, wenn seine Ergebnisse einsehbar sind. Lokal oder uebers Netz. Um auf die Frage nach Sicherheit und Kernelmodulen zurueckzukommen: In binary-only Treibern aber besonders in der kommenden Implementation von DRM sehe ich schon eine gewisse Gefahr. Wenn ich letztere richtig verstanden habe, koennte so ein Container/Schluessel der Funktion eines heutigen Modules nahe kommen? > Wie das nun mit z.B. Tan-Nummern ist (fuer die Leute die keinen > Kartenleser haben), ob man bei einer genuegenden Anzahl mitgelesener > Nummern die naechsten berechnen kann, weiss ich nicht. Ich erinnere mich, von solchen Schwachstellen gehoert zu haben. > Andreas sl ritch -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 28.03.06 10:48:20, David Haller wrote: > Hallo, > > Am Mon, 27 Mar 2006, Andreas Pakulat schrieb: > >On 27.03.06 01:35:20, Richard Mittendorfer wrote: > >> Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 01:18:48 > [..] > >> > Naja, solange der Kernel es nur root erlaubt Module zu laden ist das > >> > >> Der module autoloader (frag' mich nicht, wie der zu manipulieren sei). > > > >Aehm, ich mag mich ja irren, aber dafuer muessten die Module erstmal in > >/lib/modules// liegen und die Module Dependecies upgedated > >werden oder? > > Nein. insmod /tmp/evil_module.ko Dafuer muss er dann aber root sein und dann ist eh alles zu spaet. Andreas -- Don't relax! It's only your tension that's holding you together. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Hallo, Am Mon, 27 Mar 2006, Andreas Pakulat schrieb: >On 27.03.06 01:35:20, Richard Mittendorfer wrote: >> Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 01:18:48 [..] >> > Naja, solange der Kernel es nur root erlaubt Module zu laden ist das >> >> Der module autoloader (frag' mich nicht, wie der zu manipulieren sei). > >Aehm, ich mag mich ja irren, aber dafuer muessten die Module erstmal in >/lib/modules// liegen und die Module Dependecies upgedated >werden oder? Nein. insmod /tmp/evil_module.ko -dnh -- "DOS=HIGH ...I knew it was on something!" (UNIX user, while reading C:\CONFIG.SYS) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 28.03.06 14:50:48, Richard Mittendorfer wrote: > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 21:25:25 > +0200): > > Nee, mit Sicherheit meint er paranoia. Es geht ja um die installierbaren > > Extensions. Das sind Programme und die duerfen demzufolge alles was sie > > wollen, inkl. die Tastendruecke die du innerhalb von FF machst > > "aufschreiben" und irgendwohin schicken. Eventuell haben die sogar > > Zugriff auf X11, dann koennen sie _alle_ Tastatureingaben mitloggen. > > Fragt sich nur, ob das im Onlinebanking mit den fuer eine Sitzung > geltenden Codes ein hohes Risiko darstellt. Du gibst im Normalfall dein Passwort ein! Wenn das jemand mitliest kommt er zumindestens schon an allerlei Informationen. > Allerdings tu' ich weder onlinebanking, noch kenn ich mich in diesen > Bereichen des Webprogrammierens gut genug aus. Webprogrammierung hat damit eigentlich wenig zu tun. Wenn eine FF-Extension alle Key-Eingaben mitloggt dann ist das schon ausreichend. Wie das nun mit z.B. Tan-Nummern ist (fuer die Leute die keinen Kartenleser haben), ob man bei einer genuegenden Anzahl mitgelesener Nummern die naechsten berechnen kann, weiss ich nicht. Andreas -- Don't read everything you believe. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 21:25:25 +0200): > On 27.03.06 20:10:07, Claus Malter wrote: > > Richard Mittendorfer wrote: > > >Nobody ist nunmal auch kein so Nobody. Dennoch halte ich das fuer zu > > >pessimistisch. Deswegen ist auf meinen (privaten, ich hab keine anderen) > > >Dektops einen fuer Besucher aller Art zugaenglichen Gast-Account. Ich will > > >ja > > >auch garnicht wissen, was fuer keylogger mensch sich da mit > > >FF extensions einfangen kann.. potzblitz.. Konto leergeraeumt.. *g* > > >Und ein geladenens Evil module[tm] saesse da zweifellos ziemlich nahe an > > >der Quelle. > > > > Das löst gerade pure Panik bei mir aus. Ich bin ja ein braver und > > vorsichtiger > > Surfer, aber keylogger im Firefox beunruhigt mich doch nun sehr. Ich hoffe > > Du > > wolltest schreiben, statt ;) (du hast's nicht zitiert) war auf das binaere oder closedsource Modul (hier eines Graphikartenhersteller) bezogen. Die Extensions zum FF kannst du kontrollieren indem du dir den Code ansiehst... was natuerlich nicht viele tun. Klarerweise sollten Extensions deswegen nicht von einer xbeliebigen Seite im Netz installiert werden. Der Quelle seiner Software sollte man unbedingt vertrauen koennen, siehe die "Spyware"erweiterungen diverser Programme und OSe. Bei mit laeuft sowas auch.. popularity-contest. aber freiwillig :-) > Nee, mit Sicherheit meint er paranoia. Es geht ja um die installierbaren > Extensions. Das sind Programme und die duerfen demzufolge alles was sie > wollen, inkl. die Tastendruecke die du innerhalb von FF machst > "aufschreiben" und irgendwohin schicken. Eventuell haben die sogar > Zugriff auf X11, dann koennen sie _alle_ Tastatureingaben mitloggen. Fragt sich nur, ob das im Onlinebanking mit den fuer eine Sitzung geltenden Codes ein hohes Risiko darstellt. Allerdings tu' ich weder onlinebanking, noch kenn ich mich in diesen Bereichen des Webprogrammierens gut genug aus. > Deswegen sollte man sich genau ueberlegen welche Extensions und woher > man sie installiert. So ist das nunmal bei Software aus dem Internet und Oder eben einen Blick hinein werfen. > genau das ist auch ein Grund warum Debian seine deb's, Paketlisten und > Release-Dateien signiert und mit md5 Summen "absichert". So wird es > schon recht schwer veraenderte Pakete einzuschleusen. ack. > Andreas sl ritch
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 27.03.06 20:10:07, Claus Malter wrote: > Richard Mittendorfer wrote: > >Nobody ist nunmal auch kein so Nobody. Dennoch halte ich das fuer zu > >pessimistisch. Deswegen ist auf meinen (privaten, ich hab keine anderen) > >Dektops einen fuer Besucher aller Art zugaenglichen Gast-Account. Ich will > >ja > >auch garnicht wissen, was fuer keylogger mensch sich da mit > >FF extensions einfangen kann.. potzblitz.. Konto leergeraeumt.. *g* > >Und ein geladenens Evil module[tm] saesse da zweifellos ziemlich nahe an > >der Quelle. > > Das löst gerade pure Panik bei mir aus. Ich bin ja ein braver und > vorsichtiger > Surfer, aber keylogger im Firefox beunruhigt mich doch nun sehr. Ich hoffe Du > wolltest schreiben, statt ;) Nee, mit Sicherheit meint er paranoia. Es geht ja um die installierbaren Extensions. Das sind Programme und die duerfen demzufolge alles was sie wollen, inkl. die Tastendruecke die du innerhalb von FF machst "aufschreiben" und irgendwohin schicken. Eventuell haben die sogar Zugriff auf X11, dann koennen sie _alle_ Tastatureingaben mitloggen. Deswegen sollte man sich genau ueberlegen welche Extensions und woher man sie installiert. So ist das nunmal bei Software aus dem Internet und genau das ist auch ein Grund warum Debian seine deb's, Paketlisten und Release-Dateien signiert und mit md5 Summen "absichert". So wird es schon recht schwer veraenderte Pakete einzuschleusen. Andreas -- You display the wonderful traits of charm and courtesy. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Hallo Richard, Richard Mittendorfer wrote: [...] Ich hab mich mit der Materie noch nie derart intensiv beschaeftigt aber ich denke wer erstmal auf einem System beliebige Programme starten kann und sei es auch nur als "nobody", der hat schon fast gewonnen. Nobody ist nunmal auch kein so Nobody. Dennoch halte ich das fuer zu pessimistisch. Deswegen ist auf meinen (privaten, ich hab keine anderen) Dektops einen fuer Besucher aller Art zugaenglichen Gast-Account. Ich will ja auch garnicht wissen, was fuer keylogger mensch sich da mit FF extensions einfangen kann.. potzblitz.. Konto leergeraeumt.. *g* Und ein geladenens Evil module[tm] saesse da zweifellos ziemlich nahe an der Quelle. Das löst gerade pure Panik bei mir aus. Ich bin ja ein braver und vorsichtiger Surfer, aber keylogger im Firefox beunruhigt mich doch nun sehr. Ich hoffe Du wolltest schreiben, statt ;) [...] Andreas gruss. ritch Schleusenclaus -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 02:10:56 +0200): > On 27.03.06 01:35:20, Richard Mittendorfer wrote: > > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 > > 01:18:48 +0200): [...] > > > Naja, solange der Kernel es nur root erlaubt Module zu laden ist > > > das > > > > Der module autoloader (frag' mich nicht, wie der zu manipulieren > > sei). > > Aehm, ich mag mich ja irren, aber dafuer muessten die Module erstmal > in /lib/modules// liegen und die Module Dependecies > upgedated werden oder? Dann hat der Angreifer schon root-Zugang und es > ist eh alles zu spaet. Ohne root seh ich auch keine Probleme. Ich will keinesfalls bestreiten, das root direktes Handeln in den meisten Faellen bevorzugen wird. Und ich weiss nicht, wieweit Schwachstellen im userspace (tools wie udev, hotplug oder depmode) da mitspielen koennten. Ich sehe in "einem Kernel mit Modulen" sicherlich kein hier greifendes Sicherheitrisiko... > > > kein soo grosses Problem. Beziehungsweise wenn der Eindringling > > > schon root ist ist das kleinste Uebel wohl ob er ein Modul laden > > > darf... > > > > Und, du bist dann schoen im System eingebettet -- ohne wirkliche > > Chance von einem anti-rootkit Tool oder Sysadmin leicht entdeckt zu > > werden. > > Ich hab mich mit der Materie noch nie derart intensiv beschaeftigt > aber ich denke wer erstmal auf einem System beliebige Programme > starten kann und sei es auch nur als "nobody", der hat schon fast > gewonnen. Nobody ist nunmal auch kein so Nobody. Dennoch halte ich das fuer zu pessimistisch. Deswegen ist auf meinen (privaten, ich hab keine anderen) Dektops einen fuer Besucher aller Art zugaenglichen Gast-Account. Ich will ja auch garnicht wissen, was fuer keylogger mensch sich da mit FF extensions einfangen kann.. potzblitz.. Konto leergeraeumt.. *g* Und ein geladenens Evil module[tm] saesse da zweifellos ziemlich nahe an der Quelle. Hmm, ich hab im Augenblick keine Ahnung, was mein nvidia Modul gerade so treibt. ;-) > Und rootkit-Checker kann man doch wohl auch ohne Kernel-Modul ganz gut > austricksen, oder irre ich da? Ich meinte nicht unbedingt sowas wie chkrootkit. Nehm da gern geeigneteres wie signen oder etwas db-basierendes ala integrit und tripwire. Kommt auch den Even more evil modules[tm] und den eigenen Ungeschicklichkeiten* auf die Schliche. :-) *"Was hab ich vorgestern nur verstellt, weil heut nix mehr geht?" > Andreas gruss. ritch -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 27.03.06 01:35:20, Richard Mittendorfer wrote: > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 01:18:48 > +0200): > > On 26.03.06 22:29:13, Claus Malter wrote: > > > Richard Mittendorfer wrote: > > > >> Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib > > > >> liegen habe, die ich gar nicht brauche? > > > > > > > > Eventuell. > > > > > > Wäre interessant zu wissen. Also generell weiss ich, dass bei Modul > > > Support im Kernel es möglich ist, dass ein Eindringling sein eigenes > > > Modul in den Kernel bindet. > > > > Naja, solange der Kernel es nur root erlaubt Module zu laden ist das > > Der module autoloader (frag' mich nicht, wie der zu manipulieren sei). Aehm, ich mag mich ja irren, aber dafuer muessten die Module erstmal in /lib/modules// liegen und die Module Dependecies upgedated werden oder? Dann hat der Angreifer schon root-Zugang und es ist eh alles zu spaet. > > kein soo grosses Problem. Beziehungsweise wenn der Eindringling schon > > root ist ist das kleinste Uebel wohl ob er ein Modul laden darf... > > Und, du bist dann schoen im System eingebettet -- ohne wirkliche Chance > von einem anti-rootkit Tool oder Sysadmin leicht entdeckt zu werden. Ich hab mich mit der Materie noch nie derart intensiv beschaeftigt aber ich denke wer erstmal auf einem System beliebige Programme starten kann und sei es auch nur als "nobody", der hat schon fast gewonnen. Und rootkit-Checker kann man doch wohl auch ohne Kernel-Modul ganz gut austricksen, oder irre ich da? Andreas -- You will have a long and unpleasant discussion with your supervisor. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Mon, 27 Mar 2006 01:18:48 +0200): > On 26.03.06 22:29:13, Claus Malter wrote: > > Richard Mittendorfer wrote: > > >> Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib > > >> liegen habe, die ich gar nicht brauche? > > > > > > Eventuell. > > > > Wäre interessant zu wissen. Also generell weiss ich, dass bei Modul > > Support im Kernel es möglich ist, dass ein Eindringling sein eigenes > > Modul in den Kernel bindet. > > Naja, solange der Kernel es nur root erlaubt Module zu laden ist das Der module autoloader (frag' mich nicht, wie der zu manipulieren sei). Aber selbst da halt ich's fuer hoechst fragwuerdig, dass sich jemand die Arbeit auf deinem Desktop antut. ;-) > kein soo grosses Problem. Beziehungsweise wenn der Eindringling schon > root ist ist das kleinste Uebel wohl ob er ein Modul laden darf... Und, du bist dann schoen im System eingebettet -- ohne wirkliche Chance von einem anti-rootkit Tool oder Sysadmin leicht entdeckt zu werden. > Andreas sl ritch
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 26.03.06 22:29:13, Claus Malter wrote: > Richard Mittendorfer wrote: > >> Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib > >> liegen habe, die ich gar nicht brauche? > > > > Eventuell. > > Wäre interessant zu wissen. Also generell weiss ich, dass bei Modul > Support im Kernel es möglich ist, dass ein Eindringling sein eigenes > Modul in den Kernel bindet. Naja, solange der Kernel es nur root erlaubt Module zu laden ist das kein soo grosses Problem. Beziehungsweise wenn der Eindringling schon root ist ist das kleinste Uebel wohl ob er ein Modul laden darf... Andreas -- Don't kiss an elephant on the lips today. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Also sprach Martin Grandrath <[EMAIL PROTECTED]> (Sun, 26 Mar 2006 23:23:27 +0200): > Hallo CLaus! > > On Sunday 26 March 2006 22:29, Claus Malter wrote: > > > Wenn ich auf 'nen neuen Kernel umsteige verwende ich idR. die > > > .config des Vorgaengers. > > > > Ja normal schon. In diesem Fall ist leider die alte .config > > "verschwunden" ;) > > Wenn du in der .config die Option IKCONFIG_PROC setzt, findest du in > Zukunft die Konfiguration deines laufenden Kernels unter > /proc/config.gz. Achja, und wenn du dir die Kernel mit make-kpkg baust, hast du sie noch unter /boot/config-. sl ritch -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Hallo CLaus! On Sunday 26 March 2006 22:29, Claus Malter wrote: > > Wenn ich auf 'nen neuen Kernel umsteige verwende ich idR. die > > .config des Vorgaengers. > > Ja normal schon. In diesem Fall ist leider die alte .config > "verschwunden" ;) Wenn du in der .config die Option IKCONFIG_PROC setzt, findest du in Zukunft die Konfiguration deines laufenden Kernels unter /proc/config.gz. Gru"s, -mg- -- .--. |o_o | __ _Powered by |:_/ |/ / (_)___ __ __ __ // \ \ / / / // __ \/ / / / \/ / (| | )/ /__/ // / / / /_/ / > < /'\_ _/`\ //_//_/ /_/_/ /_/\_\ \___)=(___/ pgp5dSCVbAjmP.pgp Description: PGP signature
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Also sprach Claus Malter <[EMAIL PROTECTED]> (Sun, 26 Mar 2006 22:29:13 +0200): > [...] > Aber jedes Modul, dass in den Kernel gelinkt wird, wird doch sicher > dort auch seinen Platz in irgend einer Weise finden und somit den > Kernel "ausblähen"? Sehr wenig (BTW. leicht selber zu ueberpruefen). Diese "Schnittstellen" nehmen klar ein wenig Code in Anspruch, aber es erweitert ja nicht jedes Modul den Kern um eine komplett Neue. Im Ueblichen ist's nicht tragisch, ob da ein ein paarhundert KB den Speicher belasten. Der Codepath wird deswegen ebenfalls nicht notwendigerweise laenger. sl ritch
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Hallo Richard und alle anderen, Richard Mittendorfer wrote: >> Guten Abend, > > Auch, erstmal vielen Dank an alle, die geantwortet haben. >> ich habe gerade mein Desktop neu aufgesetzt (Etch) und wollte mir nun >> auch meinen Kernel 2.6.16 bauen. Seit der 2.6er Version fällt mir auf, >> >> dass nahezu jede denkbare Unterstützung über ein Modul selektiert >> wird. Da ich nicht wirklich jedes Modul einbinden will, frage ich >> mich wo der Sinn dahinter steckt? Ich denke, jemand der sich seinen >> Kernel selbst baut, weiss doch was er braucht und was nicht. > > Ist wohl auf Distributoren zugeschnitten, was wohl auch dem > meistverwendeten Kernel entspricht. Sinngemaess ist der auch flexibelest > konfiguriert. Wer seinen Kernel selberrollt haengt wohl nur selten > genutzte Hardware so ein -- Andererseits, wer will jedesmal den Kern neu > uebersetzen wenn eine Ethernetkarte getauscht wird oder eine > Hardwarekomponente leichter per Modulparamter konfigurierbar ist? > > Wenn ich auf 'nen neuen Kernel umsteige verwende ich idR. die .config > des Vorgaengers. Ja normal schon. In diesem Fall ist leider die alte .config "verschwunden" ;) >> Vielleicht gibt es auch einen Trick, dass ich im 'make menuconfig' >> nicht erst eine halbe Stunde damit beschäftigt bin, die Module zu >> deselektieren und dann nochmal von vorne anzufangen, weil bestimmte > > s.o. > >> Abhängigkeiten nicht abgewählt worden konnten und erst beim zweiten >> Durchlauf deselektiert werden können. > > > $ make und > defconfig - New config with default answer to all options > allmodconfig- New config selecting modules when possible > allyesconfig- New config where all options are accepted with yes > allnoconfig - New minimal config Ich denke diese Befehle werde ich mir mal anschauen. Wolf Wiegand hatte auch defconfig speziell erwähnt. Ich denke das löst mein Problem. > [...] > >> Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib >> liegen habe, die ich gar nicht brauche? > > Eventuell. Wäre interessant zu wissen. Also generell weiss ich, dass bei Modul Support im Kernel es möglich ist, dass ein Eindringling sein eigenes Modul in den Kernel bindet. In diesem Fall ist es ja "nur" ein Desktop System, somit mache ich mir diese Sorge generell nicht. Aber jedes Modul, dass in den Kernel gelinkt wird, wird doch sicher dort auch seinen Platz in irgend einer Weise finden und somit den Kernel "ausblähen"? > >> Mit freundlichen Grüßen, >> >> Claus > > sl ritch > -- Claus Malter GnuPG-ID: 0x08B86210 http://wwwkeys.de.pgp.net -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Also sprach Claus Malter <[EMAIL PROTECTED]> (Sun, 26 Mar 2006 20:24:25 +0200): > Guten Abend, Auch, > ich habe gerade mein Desktop neu aufgesetzt (Etch) und wollte mir nun > auch meinen Kernel 2.6.16 bauen. Seit der 2.6er Version fällt mir auf, > > dass nahezu jede denkbare Unterstützung über ein Modul selektiert > wird. Da ich nicht wirklich jedes Modul einbinden will, frage ich > mich wo der Sinn dahinter steckt? Ich denke, jemand der sich seinen > Kernel selbst baut, weiss doch was er braucht und was nicht. Ist wohl auf Distributoren zugeschnitten, was wohl auch dem meistverwendeten Kernel entspricht. Sinngemaess ist der auch flexibelest konfiguriert. Wer seinen Kernel selberrollt haengt wohl nur selten genutzte Hardware so ein -- Andererseits, wer will jedesmal den Kern neu uebersetzen wenn eine Ethernetkarte getauscht wird oder eine Hardwarekomponente leichter per Modulparamter konfigurierbar ist? Wenn ich auf 'nen neuen Kernel umsteige verwende ich idR. die .config des Vorgaengers. > Vielleicht gibt es auch einen Trick, dass ich im 'make menuconfig' > nicht erst eine halbe Stunde damit beschäftigt bin, die Module zu > deselektieren und dann nochmal von vorne anzufangen, weil bestimmte s.o. > Abhängigkeiten nicht abgewählt worden konnten und erst beim zweiten > Durchlauf deselektiert werden können. $ make und defconfig - New config with default answer to all options allmodconfig- New config selecting modules when possible allyesconfig- New config where all options are accepted with yes allnoconfig - New minimal config > Ich bin nicht gerade ein Pro, was den Kernel angeht. Ich bekomme es so > weit hin, dass alles funktioniert, was ich brauche. Somit weiss ich > ehrlich gesagt nicht, ob es was aus macht, wenn alle Module dem System > zur Verfügung stehen. Aber aus meiner grundlegenden Einstellung, nur > gerade so viel, wie nötig, will ich das eigentlich nicht. Obwohl ich schon Jaehrchen Kernel baue, tu' selbst ich mir bei Aenderungen oder bisher unbekannter Hardware gelegentlich schwer. Verwende besser die Konfiguration des vorherigen Kernel (im alten sourcetree ".config"). > Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib > liegen habe, die ich gar nicht brauche? Eventuell. > Mit freundlichen Grüßen, > > Claus sl ritch
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
On 26.03.06 20:24:25, Claus Malter wrote: > ich habe gerade mein Desktop neu aufgesetzt (Etch) und wollte mir nun auch > meinen Kernel 2.6.16 bauen. Seit der 2.6er Version fällt mir auf, dass nahezu > jede denkbare Unterstützung über ein Modul selektiert wird. Hae? Noe, eigentlich nicht. > Vielleicht gibt es auch einen Trick, dass ich im 'make menuconfig' nicht erst > eine halbe Stunde damit beschäftigt bin, die Module zu deselektieren und dann Aaah, was dir "passiert" ist: Der erste make menuconfig Lauf hat festgestellt das dein aktueller Kernel seine Config in /boot abgelegt hat (machen alle Debian-Kernel so) und diese als Ausgangsbasis genommen. Die Debian-Kernel bauen allerdings auch so ziemlich alles in den Kernel und natuerlich als Modul damit man bei Bedarf nachladen kann. > nochmal von vorne anzufangen, weil bestimmte Abhängigkeiten nicht abgewählt > worden konnten und erst beim zweiten Durchlauf deselektiert werden können. rm .config touch .config Oder auch rm .config make defconfig > Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib liegen habe, > die ich gar nicht brauche? Speicherverbrauch. Manchmal laedt dir hotplug dann auch Module obwohl die Hardware gar nciht da ist. Was auch haeufiger passiert ist dass der ub-Treiber fuer USB-Storage Geraete genommen wird, statt das ganze ueber SCSI-Devices zu machen. Andreas -- Your ignorance cramps my conversation. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Claus Malter <[EMAIL PROTECTED]> wrote: > ich habe gerade mein Desktop neu aufgesetzt (Etch) und wollte mir nun > auch meinen Kernel 2.6.16 bauen. Seit der 2.6er Version fällt mir auf, > dass nahezu jede denkbare Unterstützung über ein Modul selektiert > wird. Da ich nicht wirklich jedes Modul einbinden will, frage ich > mich wo der Sinn dahinter steckt? Ich denke, jemand der sich seinen > Kernel selbst baut, weiss doch was er braucht und was nicht. Du hast vorher einen Debian-Kernel benutzt? Dann übernimmt das "make menuconfig" bei Abwesenheit einer .config im Source-Verzeichnis die Konfiguration, die unter /boot/config-`uname-r` zu finden ist, also die vom Debian-Kernel, welcher, damit er nahezu überall läuft, bis ins letzte modularisiert ist. > Vielleicht gibt es auch einen Trick, dass ich im 'make menuconfig' nicht > erst eine halbe Stunde damit beschäftigt bin, die Module zu > deselektieren und dann nochmal von vorne anzufangen, weil bestimmte > Abhängigkeiten nicht abgewählt worden konnten und erst beim zweiten > Durchlauf deselektiert werden können. make allnoconfig S° -- Sven Hartge -- professioneller Unix-Geek Meine Gedanken im Netz: http://www.svenhartge.de/ -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Das Deselektieren von Kernel 2.6 Modulen
Hallo, Claus Malter wrote: > Vielleicht gibt es auch einen Trick, dass ich im 'make menuconfig' > nicht erst eine halbe Stunde damit beschäftigt bin, die Module zu > deselektieren und dann nochmal von vorne anzufangen, weil bestimmte > Abhängigkeiten nicht abgewählt worden konnten und erst beim zweiten > Durchlauf deselektiert werden können. Ich bin mit dem, was 'make defconfig' erstellt, eigentlich recht zufrieden (Tipp: Es gibt auch noch make help (-: ). > Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib liegen > habe, die ich gar nicht brauche? Eigentlich nicht, wenn man nicht am Festplattenplatz sparen muss. Wolf -- Als ich gehört habe, der Kanzler führt uns in den Untergang, dachte ich: Super, endlich mal in's Kino mit dem Regierungschef. (Harald Schmidt) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
OT: Das Deselektieren von Kernel 2.6 Modulen
Guten Abend, ich habe gerade mein Desktop neu aufgesetzt (Etch) und wollte mir nun auch meinen Kernel 2.6.16 bauen. Seit der 2.6er Version fällt mir auf, dass nahezu jede denkbare Unterstützung über ein Modul selektiert wird. Da ich nicht wirklich jedes Modul einbinden will, frage ich mich wo der Sinn dahinter steckt? Ich denke, jemand der sich seinen Kernel selbst baut, weiss doch was er braucht und was nicht. Vielleicht gibt es auch einen Trick, dass ich im 'make menuconfig' nicht erst eine halbe Stunde damit beschäftigt bin, die Module zu deselektieren und dann nochmal von vorne anzufangen, weil bestimmte Abhängigkeiten nicht abgewählt worden konnten und erst beim zweiten Durchlauf deselektiert werden können. Ich bin nicht gerade ein Pro, was den Kernel angeht. Ich bekomme es so weit hin, dass alles funktioniert, was ich brauche. Somit weiss ich ehrlich gesagt nicht, ob es was aus macht, wenn alle Module dem System zur Verfügung stehen. Aber aus meiner grundlegenden Einstellung, nur gerade so viel, wie nötig, will ich das eigentlich nicht. Hat es denn einen Nachteil, wenn ich hunderte von Module in /lib liegen habe, die ich gar nicht brauche? Mit freundlichen Grüßen, Claus -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
