Login
Newsletter
Werbung

Thema: Debian-Server nach Einbruch wiederhergestellt

53 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
mehr -
0
Von Tim am Fr, 14. Juli 2006 um 11:22 #
Tjaja, das wirklich fehlerbehaftete war also nicht der Linux-Kernel sondern der Linux-User vor dem Rechner...
[
| Versenden | Drucken ]
  • 0
    Von G. W. am Fr, 14. Juli 2006 um 11:48 #
    ARGH!

    Sollen wir die Diskussion also wiederholen, ja? Eigentlich ging ich davon aus, die Frage sei geklärt, aber irgendwie scheint sich doch immer wieder jemand berufen zu fühlen, Linux-Bugs um jeden Preis zu relativieren.

    Jemand, der aus welchem Grund auch immer einen Account auf diesem Rechner hatte, welcher kein root-Account war, konnte durch ein Kernel-Bug seinen Nicht-root-Account dazu benutzen, Dinge zu tun, die sonst nur root kann. Das ist ein Kernel-Bug ist ein Kernel-Bug ist ein Kernel-Bug.

    Es ist genau umgekehrt: Das wirklich fehlerbehaftere ist selbstverständlich sehr wohl CVE-2006-2451, ohne CVE-2006-2451 hätte diese Person nämlich gar nichts schädliches anrichten können.

    Aber relativier ruhig weiter - dass Du damit das Sicherheitskonzept von Linux bzw. UNIX ins Lächerliche ziehst, merkst Du wahrscheinlich gar nicht mehr. Selbstverständlich ist es ein Bug und kein Benutzerproblem, wenn ein Benutzer seine Rechte erhöhen kann, und das ist nicht zu relativieren.

    [
    | Versenden | Drucken ]
    • 0
      Von blablabla am Fr, 14. Juli 2006 um 12:13 #
      Na wer fängt ne Diskussion an? GehWeg...du tust mir leid.
      [
      | Versenden | Drucken ]
      • 0
        Von G. W. am Fr, 14. Juli 2006 um 18:08 #
        > GehWeg...du tust mir leid.

        Mit wem sprichst Du?

        Sehr leid tut es mir, dass manch einer so derart hart getroffen ist, dass er aber auch wirklich immer persönlich werden muss.

        [
        | Versenden | Drucken ]
        • 0
          Von Blobloblo am Fr, 14. Juli 2006 um 18:53 #
          Ach, das liegt nur an der Art deiner Postings; die erzeugen halt einen Kackreiz. Als Abführmittel würdest Du bestimmt eine gute Figur machen.

          Der Inhalt deiner Postings ist es jedenfalls nicht. Das Thema wird auch ohne Dich kontrovers diskutiert. Aber du darfst gerne weiterblubbern.

          [
          | Versenden | Drucken ]
          • 0
            Von G. W. am Fr, 14. Juli 2006 um 20:12 #
            Das waren noch viel zu wenige Fäkalien. Da ist bestimmt noch mehr drin: Los, raus damit.
            [
            | Versenden | Drucken ]
      0
      Von cheese am Fr, 14. Juli 2006 um 12:24 #
      Nein, die Frage wird wohl nie geklärt sein, da es immer wieder Menschen geben werden, die im Gegensatz zu Dir eine subjektive Meinung haben und nicht immer vollkommen objektiv die Dinge bewerten. Deshalb wird es wohl auch immer Leute geben die einfach behaupten, daß der Kernel-Bug nur ausgenutzt werden konnte, weil der Angreifer sich schon durch ein unsicheres Passwort auf dem Rechner war - immerhin ist das ja auch die Aussage der Debian-Crew. Andererseits hast Du bislang aber auch noch nicht dargelegt, daß der Kernel-Bug auch ohne den bereits erfolgten Angriff auf den Benutzeraccount möglich gewesen wäre. Vielleicht solltest Du dort noch eine Quellenangabe einfügen, die die Debian-Behauptung wiederlegt, das könnte helfen. Solange werden die meisten Leute es wohl weiterhin als eine Kombination aus Benutzerproblem und Kernelbug ansehen, mit unterschiedlicher Gewichtung selbstverständlich.
      [
      | Versenden | Drucken ]
      • 0
        Von G. W. am Fr, 14. Juli 2006 um 18:16 #
        > Andererseits hast Du bislang aber auch noch nicht dargelegt,
        > daß der Kernel-Bug auch ohne den bereits erfolgten Angriff
        > auf den Benutzeraccount möglich gewesen wäre.

        Das braucht auch niemand gesondert darzulegen, es steht nämlich direkt in CVE-2006-2451, wo es jeder nachlesen kann.

        Jeder mit einem lokalen Benutzerkonto hätte das ping-Binary überschreiben können, und an ein lokales Benutzerkonto zu kommen, setzt nicht zwingend einen technischen Angriff voraus. Es gibt auch sowas wie "Social Engineering" (d.h. man könnte z.B. versuchen, durch bewusst geknüpfte Beziehungen ganz ohne technische Mittel an ein Benutzerkonto zu kommen).

        [
        | Versenden | Drucken ]
      0
      Von eben nicht! am Fr, 14. Juli 2006 um 12:26 #
      es war eben nicht ein fehler des Kernel teams, weil diese den bug längst gefixt hatten. debian hatte seinen server nicht aktualisiert, und das war die zeitbombe die dann auch gezündet hatte.
      [
      | Versenden | Drucken ]
      0
      Von Michael am Fr, 14. Juli 2006 um 12:26 #
      bla bla sülz bla troll bla troll sülz sülz lamentier bla sülz troll provozier sülz lüg sülz bla fasel lüg provozier troll troll troll troll troll

      Ich hab deinen Beitrag mal übersichtlicher gestaltet.

      PS: Die Lücke war extrem leicht zu schliessen... Userfehler.

      [
      | Versenden | Drucken ]
      • 0
        Von G. W. am Fr, 14. Juli 2006 um 18:10 #
        > Ich hab deinen Beitrag mal übersichtlicher gestaltet.

        Nein, Du hast Dich ins Bodenlose blamiert.

        > Die Lücke war extrem leicht zu schliessen... Userfehler.

        Manch einer wird es nie begreifen. Ein Bug bleibt auch dann immer noch ein Bug, wenn es einen Fix gibt. Dann ist es ein sog. gefixter Bug. Dadurch geht der Bug als solcher aber nicht auf, ein Bug zu sein.

        [
        | Versenden | Drucken ]
      0
      Von W.G. am Fr, 14. Juli 2006 um 12:41 #
      Nein, G.W., du sollst die Diskussion nicht wiederholen. Du musst noch nicht einmal antworten, niemand hätte etwas vermisst.
      [
      | Versenden | Drucken ]
      • 0
        Von G. W. am Fr, 14. Juli 2006 um 18:11 #
        Tja - Wie schwer es manch einem doch fällt, nicht persönlich zu werden, ist doch wirklich immer wieder erstaunlich.
        [
        | Versenden | Drucken ]
        • 0
          Von W.G. am Fr, 14. Juli 2006 um 18:19 #
          Tja - Wie schwer es manch einem doch fällt, eine Tatsachenfeststellung nicht als persönliche Bemerkung hinzunehmen, ist doch immer wieder erstaunlich.
          [
          | Versenden | Drucken ]
          • 0
            Von G. W. am Fr, 14. Juli 2006 um 20:14 #
            Oh, da ist wohl jemand, der es pflegt, für andere zu sprechen und etwas, das er selbst persönlich vorher im Konjunktiv formulierte, zur Tatsachenfeststellung zu erheben. Diese Sorte mag ich ganz besonders. Mehr davon, bitte!
            [
            | Versenden | Drucken ]
      0
      Von 2old4these am Fr, 14. Juli 2006 um 13:20 #
      Der fragliche Entwickler-Account wurde möglicherweise durch ein leicht zu erratendes Passwort kompromittiert. Eine Überprüfung aller Entwicklerkonten deckte eine weitere Anzahl zu schwacher Passwörter auf. Diese Konten wurden bis auf weiteres gesperrt.

      es wurde gestern schon gemeldet, dass möglicherweise ein Passwort nicht sicher war!

      Aber GeWe muss ja wieder mal den Troll spielen und einfach drauf losblubbern !

      Allen anderen ein schönes Wochenende

      [
      | Versenden | Drucken ]
      • 0
        Von fuffy am Fr, 14. Juli 2006 um 13:34 #
        es wurde gestern schon gemeldet, dass möglicherweise ein Passwort nicht sicher war!
        Ja und? Selbst dann sollte so etwas nicht vorkommen. Der Administrator hat dafür zu sorgen, dass kein Benutzer dem System Schaden zufügen kann, d.h. er hätte den 2.6.16.24 einspielen müssen.
        [
        | Versenden | Drucken ]
        0
        Von Amtsleiter Merkbefreiung am Fr, 14. Juli 2006 um 13:41 #
        Die Tatsache das sich G.W. nicht gerade allergrößter Beliebtheit erfreut, ändert genau nichts daran, daß auf der Kiste ein Kernel mit bekannt kaputtem Code lief.
        Wenn es in meiner Bude rumpelt werd ich sagen: "Nee Cheff, ich kann nichts dafür. G.W. hat gesagt ich hätte Schuld. Und der ist bekanntlich doof und deshalb ist hier alles in Butter."
        Na, das ist doch leichter als Löcher stopfen.

        *kopfschüttel*

        [
        | Versenden | Drucken ]
        • 0
          Von 2old4these am Fr, 14. Juli 2006 um 20:03 #
          >Nee Cheff, ich kann nichts dafür. G.W. hat gesagt ich hätte Schuld.<

          warum sollte ich den Troll zitieren :-)

          da ware ich lieber Abstand, vielecht ist der ansteckend!

          [
          | Versenden | Drucken ]
          • 0
            Von G. W. am Fr, 14. Juli 2006 um 20:18 #
            Warum man Aussagen, auf die man sich bezieht, zitieren sollte? Ganz einfach: Weil es bei persönlichen Bemerkungen immer sehr vorteilhaft ist zu belegen, auf welche Aussagen sie sich beziehen. Ansonsten ist es einfach zu offensichtlich, dass es ausschließlich ums Persönliche geht.
            [
            | Versenden | Drucken ]
        0
        Von dem langhaarigen Unixfossil am Fr, 14. Juli 2006 um 15:50 #
        Kernelbug ist Kernelbug.

        Wären alle User brav und hätten alle User sichere Passwords, wäre wohl Nichts passiert.
        Sicherheit ist eine Zwiebel.
        Es mussten mehrere Verteidigungringe fallen, um diesen "Skandal" zu erzeugen.
        Soll ich dem BND nun mal mehrkreisige Skizzen machen?
        Ööööö das war ein anderes Thema. Na gut!

        Interessant finde ich, wie ein Befürworter des meistkompromitierten OS dieses nun Ausschlachtet, jedoch ändert auch eine Kritische Distanz zu ihm nichts daran, daß ein Kernelbug nunmal ein Kernelbug ist.

        [
        | Versenden | Drucken ]
        • 0
          Von 2old4these am Fr, 14. Juli 2006 um 20:09 #
          full ack !

          Sicherheit heisst nicht nur Airbag vorne und ABS hinten, sondern ringsum sicher machen!

          klar, Kernel-update wäre schon besser gewesen, aber das heißt nicht alles andere außeracht zu lassen.

          >meistkompromitierten OS dieses nun Ausschlachtet...<

          lass mal den µ$- Nachtwächter doch blubbern, irdendwann wacht der auch mal auf .-)

          [
          | Versenden | Drucken ]
          • 0
            Von G. W. am Fr, 14. Juli 2006 um 20:16 #
            > µ$

            Nur ein Millionstel eines Dollars? Mehr ist nicht drin? Das ist aber schade.

            [
            | Versenden | Drucken ]
            • 0
              Von 2old4these am Fr, 14. Juli 2006 um 20:31 #
              mehr ist dein Geblubber nicht wert :-))
              [
              | Versenden | Drucken ]
        0
        Von G. W. am Fr, 14. Juli 2006 um 18:12 #
        > Aber GeWe muss ja wieder mal den Troll spielen und
        > einfach drauf losblubbern !

        Du scheinst da irgendeinen "GeWe" mit "2old4these" zu verwechseln, darfst aber selbstverständlich gerne weiterblubbern.

        [
        | Versenden | Drucken ]
      0
      Von Neuer am Fr, 14. Juli 2006 um 18:19 #
      Da hast Du Recht: Das "wirklich" hätte man sich sparen müssen. Er meinte wohl, dass es ohne den menschlichen Fehler den lokalen Login auf einen so wichtigen Rechner zuzulassen, nicht möglich gewesen wäre.

      Aber Du hast auch Unrecht: Der Linux-Kernel hat mit Garantie noch jede Menge bekannte und unbekannte Probleme, die das gleiche gestatten.

      Die Fragen sind doch:

      1. Wie konnte es sein, dass der Fix von CVE-2006-2451 nicht auf dem Rechner installiert war, obwohl schon länger verfügbar? Eindeutig ein menschliches Problem.
      2. Wie konnte jemand für einen so wichtigen Rechner ein zu schwaches Passwort einsetzen? Eindeutig ein menschliches Problem.
      3. Wie konnte das unbemerkt bleiben? Eindeutig ein menschliches Problem, denn die Reaktion zeigt, dass es möglich war, jetzt diese Fälle durch zu scannen.

      Du solltest begreifen, dass man immer davon ausgehen wird müssen, dass es solche Fehler im Linux-Kernel gibt und deshalb der Zugriff als Linux-User auf der Maschine einem besonderen Schutz unterliegen muss, der der Wichtigkeit des Rechners angemessen ist.
      Du solltest begreifen, dass man ferner auch immer entfernte Angriffe wird machen können.

      Haupt-Probleme an Bugs folgende:

      a) Mit der Veröffentlichung des Fehlers oder seiner Korrektur, wird jeder Böswillige sofort in die Lage versetzt, eine Analyse zu machen, wie er das Ausnutzen kann, bei Systemen, die nicht die Korrektur haben.

      b) Es gibt keine nicht-triviale oder fehlerfreie Software. Keine Methode kann diese erstellen.

      Das Wichtigste ist daher immer der Umgang des Menschen mit den fehlerhaften Systemen. Die Vermeidung der Exposition des Systems wo es nur geht.

      Die Logins der Entwickler müssen besser geschützt werden. Aber seiner Natur gemäss, hat Debian das Problem aus vielen Leuten zu bestehen, die alle auch individuelle Fehler machen.

      Im Grunde finde ich aber brilliert Debian hier. Das Problem wurde gelöst, bevor es richtig anfing zu existieren. Konkrete Erkenntnisse führen dazu, dass alle Accounts jetzt sicherere Passwörter haben müssen. Und man macht den Umgang mit dem Problem öffentlich.

      Nur so kann ich Debian vertrauen, hm, obwohl ich ja nun Kubutu Edgy benutze :p

      Gruß, Kay

      [
      | Versenden | Drucken ]
    0
    Von Entropie am Fr, 14. Juli 2006 um 12:39 #
    Meine Nutzer haben bei der Auswahl ihrer Passwörter gewissen Anforderungen zu genügen. Die betreffende Maschine hatte wohl keinen Administrator? Nunja, unsichere Authentifizierung schein politisch weniger brisant als kaputter Code. Insofern ist das Projekt jungfräulich rein. MUAHAHAHA
    [
    | Versenden | Drucken ]
    • 0
      Von fuffy am Fr, 14. Juli 2006 um 13:35 #
      Was bringen dir sichere Kennwörter, wenn der Angriff von innen, hier also von einen Debian-Entwickler, käme?
      [
      | Versenden | Drucken ]
      • 0
        Von Hilfsschule am Fr, 14. Juli 2006 um 13:51 #
        Der Angreifer findet keine bekannten Bugs? Sacht mal was ist hier eigentlich los? Ferien, Politik oder was? Auch für den letzten der es nicht höhren will.
        Das Betriebssystem lief mit ungefixtem Kernel. Der Admin betrieb wissentlich ein verwundbares Sytem. Da hing eine kaputte Kiste am Netz. Immernoch fragen? Ja? Sie sind gefeuert. Und sie können sicher sein, nach der Kanone die sich geleistet haben können sie sehr lange nach nem neuen Job oder Kunden suchen.

        *Aua*, echt jetzt, das geht doch gar nicht mehr

        [
        | Versenden | Drucken ]
        • 0
          Von Hilfsschule am Fr, 14. Juli 2006 um 14:00 #
          Nachtrag.

          @fuffy
          War nicht persönlich gemeint. Ich krieg da nur die Krise wenn jemand wissentlich ein fehlerhaftes System betreibt und dann rumfenzt und vom eigenen Versagen ablenkt. Da war der Puls leider etwas hoch, sry.

          [
          | Versenden | Drucken ]
          0
          Von fuffy am Fr, 14. Juli 2006 um 18:40 #
          Der Angreifer findet keine bekannten Bugs?
          Wenn der Angreifer ein frustrierter Debian-Entwickler gewesen wäre, dem der lokale Login gestattet worden wäre, hätte auch das sicherste Kennwort nichts gebracht, wenn dieser die Lücke im Kernel ausgenutzt hätte.

          Das Betriebssystem lief mit ungefixtem Kernel.
          Das habe ich schon weiter oben geschrieben.

          Der Admin betrieb wissentlich ein verwundbares Sytem. Da hing eine kaputte Kiste am Netz.
          Ja, eben. Genau das ist das Problem, nicht unsichere Benutzerkennwörter. Unsichere Benutzerkennwörter dürfen, wenn überhaupt, nur dazu führen, dass der betreffende Account kompromittiert wird. Das System an sich darf dadurch nicht in Leidenschaft gezogen werden. Ein Administrator hat das System vor den eigenen Benutzern zu schützen, sonst könnte man Benutzern gleich sämtlichen Benutzern die UID 0 zuteilen.

          Nichts für ungut.

          [
          | Versenden | Drucken ]
    0
    Von Huy Dinh am Fr, 14. Juli 2006 um 12:45 #
    Laege der Fehler auch am User, wenn sich einer der Entwickler, strebend nach der Macht des roots auf ``Gluck'', die Luecke im Kernel zu Nutze gemacht haette? Waere dann nicht auf einmal doch der Kernel daran Schuld gewesen, dass ``Gluck'' kompromittiert werden konnte?

    Der Kernel hatte diese Luecke; dass nun wahrscheinlich ein zu schwaches Benutzerpasswort jemandem die Moeglichkeit gegeben hat, diese Luecke auszunutzen, mag zwar stimmen, aber ohne die Luecke im Kernel waere es nie so weit gekommen. Von daher ist auch der Kernel wirklich fehlerbehaftet gewesen, und daran aendert auch nicht die Tatsache, dass der Bug leicht behebbar gewesen ist -- er war da und er wurde genutzt.

    [
    | Versenden | Drucken ]
0
Von Felix am Fr, 14. Juli 2006 um 12:46 #
Das ist echt eine blöde Sache mit den Mehrbenutzersystemen. So schnell kann ein Administrator ja gar nicht sein wie es nötig ist.
Wenn heute um 14:00 Uhr eine Lücke bekannt wird, der Hacker aber bereits Zugang zum System hat, dann hat der Admin keine Chance.

Was sind also die Lösungen ?

Nie wieder Lücken im Kernel und sonst wo ? Unrealistisch
Besseres IDS ? Da ist es schon zu spät, auch wenn es im Nachhinein hilft
RW remount von /usr nur mit über Serielle Konsole erlauben, würde das gehen ?
Root Erlaubniss nur wenn man einen entsprechenden Key hat den man auch remote per ssh verwenden kann ? Würde doch sicher helfen oder ?

Auf jeden Fall ist wohl auf den Debian Servern spätestens ab jetzt eine Überprüfung der Passwörter bei Erstellung und Änderung gefragt. Genauso wie der Abgleich der Prüfsummen aller Dateien in $PATH mit einer externen sicheren readonly Liste.


felix

[
| Versenden | Drucken ]
  • 0
    Von Felix am Fr, 14. Juli 2006 um 12:51 #
    Wobei das nicht heissen soll das Debian das Kernel Update nicht hätte schneller aufspielen können und damit vieleicht zumindest diesen Einbruch hätte verhindern können. Das oben ist eher eine generelle Frage aus Interesse   ;)
    [
    | Versenden | Drucken ]
    0
    Von filthgrinder am Fr, 14. Juli 2006 um 14:16 #
    Warum nicht SE Linux?

    SE Linux kapselt jeden Prozess (also auch User) in einer eigenen Domäne. Domänentransitionen sind
    nur durch _ausdrückliche_ Erlaubnis in der Policy möglich.
    Ein User kann sich auf SE Linux-gesicherten Systemen keine root-Rechte erschleichen, da z.B. Buffer Overflows nicht aus ihrer Domäne herauskommen.
    Beispiel: Ein Apache, dem über einen Buffer Overflow ein Injection Vector untergejubelt wurde
    stürzt zwar ab, da aber der Apache keine Shell starten darf (unter SE Linux darf zunächst einmal
    keiner irgendetwas), bleiben Exploits wirkungslos.

    Es gibt nur 2 Haken:
    1. SE Linux schützt nicht vor schwachem Root-Passwort
    2. Die Administration ist eine echte Herkulesaufgabe (extrem komplexes Regelwerk)

    Bleibt also nur zu hoffen, dass SE Linux schleunigst in Debian Einzug hält.

    Hier ein wenig Lesestoff:
    http://www.computerwoche.de/knowledge_center/linux/558221/
    http://www.nsa.gov/selinux/

    Wer sich beweisen will:
    http://www.coker.com.au/selinux/play.html
    Und hier Russel Cokers Doku zur Playmachine:
    http://www.selinux-symposium.org/2005/presentations/session7/7-1-coker.pdf

    [
    | Versenden | Drucken ]
    • 0
      Von Felix am Fr, 14. Juli 2006 um 16:18 #
      Das stimmt, SE Linux ist eine der Techniken die auf jeden Fall helfen würden. Wenn auch hier im Cron Fall nicht, oder ?

      Dank und Gruß
      Felix

      [
      | Versenden | Drucken ]
      • 0
        Von filthgrinder am Di, 18. Juli 2006 um 10:20 #
        Das stimmt, SE Linux ist eine der Techniken die auf jeden Fall helfen würden. Wenn auch hier im Cron Fall nicht, oder ?
        Hmmm ... ich muss gestehen, ich bin mir nicht sicher ;-)
        Ob SE Linux hier helfen kann müsste man wissen, wie genau der Dump geschieht. Wenn dies ein Prozess aus dem Userspace übernimmt, sehe ich da gute Chancen. Für den Fall, dass der Kernel selbst das macht habe ich so meine Bedenken.
        Ich vermute aber, dass man Cron davor bewahren könnte, die Datei zu starten (denn für sie existiert ja keine Policy-Regel)

        Grüße,

        filthgrinder

        [
        | Versenden | Drucken ]
0
Von einem göttlich unmutenden User am Fr, 14. Juli 2006 um 12:53 #
Eigentlich kann es doch nicht so schwer sein das Paßwort beim Anlegen durch eine Reihe regulärer Ausdrücke prüfen zu lassen und somit eine hohe Sicherheit zu erzielen. Irgendwie habe ich den Eindruck, daß in dem Debianprojekt doch nicht die allerbesten Köpfe der Linux-Szene arbeiten...

Was den Bug betrifft... -> Mit SuSE wäre das nicht passiert... :)

[
| Versenden | Drucken ]
0
Von sleipnir am Fr, 14. Juli 2006 um 14:36 #
PEBKAC gibts eben auch bei Entwicklern...

Hätte es aber nicht für möglich gehalten, dass die sich da die Passwörter so frei auswählen dürfen, dass man sie per Dictionary Attacken rausbekommen kann...

[
| Versenden | Drucken ]
  • 0
    Von fuffy am Fr, 14. Juli 2006 um 18:44 #
    Selbst dann hätte immer noch eine der Personen, die rechtmäßig Shell-Zugriff auf den Rechner haben, das System kompromittieren können.
    Es ist Sache des Administrators, dafür zu sorgen, dass ein normaler Benutzer (UID > 0) das System nicht lahmlegen kann.
    Wenn du zu deinen Benutzern vollstes Vertrauen hättest, könntest du ihnen gleich dein root-Kennwort geben. ;-)
    [
    | Versenden | Drucken ]
0
Von Erik am Fr, 14. Juli 2006 um 15:43 #
... bezüglich des Logins der User.

Aufgabenstellung: neuer User bekommt Account.
0) Zugang per Passwort auf die Server wird abgestellt
1) User und Admin tauschen ihre GPG-Identitäten untereinander aus
2) User schickt Admin einen seiner öffentlichen SSH-Schlüssel und signiert die dazugehörige Email
3) Admin erzeugt Account und trägt den SSH-Schlüssel vom User in die authorized_keys ein
4) Admin schickt User die Accountdaten in verschlüsselter Email
5) Ein Jahr später muß (meinethalben über einen Emaildienst) ein neuer öffentlicher SSH-Schlüssel übermittelt werden
6) Account wird gesperrt, falls 5) nicht innerhalb eines Monats vor Ablauf des Jahres durchgeführt wird

Sobald Schritt 1 manuell durchgeführt wurde, kann der Rest komplett automatisiert werden und es fliessen keine Passwörter mehr.


lg
Erik

[
| Versenden | Drucken ]
  • 0
    Von zobel am Fr, 14. Juli 2006 um 19:08 #
    gpg --clearsign < ~/.ssh/id_dsa.pub | mail change@db.debian.org
    [
    | Versenden | Drucken ]
    0
    Von Benni am Sa, 15. Juli 2006 um 11:15 #
    Das Problem ist, das dies in einigen Ländern illegal ist, entweder aufgrund Patente oder Gesetzen gegen Privatsphäre/Verschlüsselungen. Debian will aber möglichst allen zugänglich sein, daher kommt eine solche Lösung nur schwer in Frage. Und Accounts 1. und 2. Klasse will keiner.
    [
    | Versenden | Drucken ]
    • 0
      Von Erik am Sa, 15. Juli 2006 um 12:02 #
      > Das Problem ist, das dies in einigen Ländern illegal ist
      Und trotzdem ist ein Login auf den Servern nur per SSH erlaubt? SSH verschlüsselt die Session auf beiden Seiten, also auch im Land, in dem Verschlüsselung verboten ist (wo eigentlich ausser in Russland und irgendwelchen Diktaturen?). Dann müßte man konsequenterweise auf jegliche Verschlüsselung verzichten und das ist nicht drin.


      lg
      Erik

      [
      | Versenden | Drucken ]
      • 0
        Von Benni am Sa, 15. Juli 2006 um 14:02 #
        Such mal auf den debian-dev Listen, da gab es mal einen langen Thread dazu. Die Verschlüsselung selbst ist nicht das Problem, sondern die Verwendung von public keys. Einfache Passwörter sind erlaubt, weil man die per Beugehaft in Erfahrung bringen kann.
        [
        | Versenden | Drucken ]
        0
        Von the-me am Mo, 17. Juli 2006 um 02:41 #
        In den USA sind zB die guten alten PGP versionen verboten, da sie kein hintertürchen haben, demnach unknackbar sind ( außer man will alt und grau werden ). daraufhin hat man entsprechendes eingebaut und seitdem dürfen die neueren versionen in den USA verwendet werden.
        Un die USA ist ja wohl *hust* eine demokratie *kotter*
        [
        | Versenden | Drucken ]
        • 0
          Von Meckeronkel am Mo, 17. Juli 2006 um 14:09 #
          Hmm, Demokratie -- wurde nicht auch der Führer und seine braune Brut mehrheitlich gewählt? Der Spitzbart und der Dachdecker (bzw. ihr Verein) bekam auch 40 Jahre die Stimmenmehrheit, selbst wenn wir die zugemogelten abziehen. Später behaupten meine Nachbarn, sie durften 40 Jahre nicht frei wählen. Nun gut, vielleicht nicht ganz frei, aber sie hätten NEIN sagen können. Aber wozu, ist doch alles richtig, was aus Bonn/Berlin, Washington, Tel Aviv ... kommt.
          Ach ja, Linux & Co. -- es geht zielstrebig den Bach hinunter, ganz demokratisch.
          [
          | Versenden | Drucken ]
0
Von Harald am Sa, 15. Juli 2006 um 15:50 #
Aus dem Newsbeitrag:

> Die Lücke betrifft alle Kernel-Versionen von 2.6.13 bis 2.6.16.23 bzw. 2.6.17.3.

Das ist so nur für ungepatchte Kernel richtig.
Die verschiedenen Distributionen, die ältere Kernel einsetzen, haben für diese meist schon lange entsprechend gepatchte Kernelupdates herausgebracht.

...nur um mal ein paar Leute zu beruhigen... ;-)

[
| Versenden | Drucken ]
0
Von Jens am Mi, 19. Juli 2006 um 10:15 #
Heute kam der aktualisierte Kernel für Ubuntu Dapper, wie sieht es bei den anderen Distris aus?
[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung