Sicherheit unter Linux

Übersicht

Sie sind der einzige Benutzer in Ihrem System? Ihr System ist in keinem Netzwerk integriert und besitzt auch keinerlei Verbindung zum Internet? Sie arbeiten auch nur unter dem Root-Zugang, wenn es unabdingbar ist?

Dann mögen die hier besprochenen Themen Sie nicht betreffen, aber vielleicht verleitet Sie ja die Neugier, unseren Ausführungen dennoch zu folgen.

Die Sicherheit in einem Linuxsystem ist viel gestaltig. Dies beginnt schon beim Booten des Rechners. Wer ist dazu berechtigt? Wer darf das System herunterfahren? Was wäre, wenn ein Eindringling Ihren Webserver stoppen würde?

Alle Befugnisse einer Person zuzusprechen, ermöglicht dieser die volle Kontrolle über das System. Die Sicherheit des Systems steht und fällt mit den Fähigkeiten des Administrators, Schwachpunkte zu erkennen und Schlupflöcher zu schließen. Die Achillesferse jener Methodik ist in der Stärke des Rootpasswortes verborgen. Gelingt einem Angreifer dieses zu umgehen, hält er alle Instrumente in seiner Hand.

Ein Angreifer kann sich mehrere Techniken bedienen, um seine Befugnisse in einem System zu erweitern. Zu liberale Berechtigungen verhelfen ihm ebenso zur Implementierung trojanischer Pferde, wie die leichtfertige und dennoch verbreitete Aufnahme des aktuellen Verzeichnisses in die Suchpfade für Kommandos.

Vorab aber etwas Entwarnung: Solche Horrorszenarien, wie sie immer wieder von Viren unter einigen populären Systemen herauf beschworen werden, sind unter einem Unixsystem kaum möglich.

Sichere Passwörter

Zunächst sollten Sie sich einmal in die Lage eines Hackers versetzen. Wer ist er und wie geht er vor? Sie können davon ausgehen, dass es sich um einen absoluten Spezialisten handelt, der aufmerksam die Hinweise auf neueste Sicherheitslücken von Programmen verfolgt und sie zu seinen Gunsten zu nutzen weiß. Er ist ebenso ein guter Programmierer wie auch ein Administrator. Zum Glück versteht er seine Handlungen zumeist nur als »kleine Fingerübung« und wird nach gelungenem Einbruch keinen wirklichen Schaden anrichten. Aber darauf sollten Sie nicht vertrauen.

Das primäre Ziel des Hackers ist der Zugang zu einem Rechner. Idealerweise handelt es sich um den Rootzugriff. Jedoch sind sich Administratoren der Sicherheitsproblematik bewusst und verwenden daher als sicher (?) einzustufende Passwörter. Aber der »normale« Benutzer? Er ist wenig geneigt, kryptische Buchstabenkombinationen zu pauken, wechselt selten das Passwort und beschränkt sich bei der Wahl auf Begriffe aus seinem sozialen Umfeld, die er, um sie zu verkomplizieren, rückwärts buchstabiert. Für einen Hacker schwerer zu knacken? Mitnichten, wie Sie noch lesen werden.

Eine gänzlich andere Methode ist die Ausnutzung von Programmfehlern. Hierfür benötigt ein Angreifer detailliertes Wissen über die Anordnung der Daten eines Programms im Hauptspeicher und über die Schwachstelle des Programms selbst. Er provoziert bspw. in Programmen, die ihre Eingaben ungenügend auf Korrektheit testen, durch anscheinend unsinnige (aber exakt geplante) Eingaben Speicherüberläufe, sodass der ursprüngliche Speicherbereich des Programms überschrieben wird (Buffer overflow). Wenn es dem Angreifer gelingt, den Speicherinhalt gezielt durch eigene Befehle zu ersetzen (z.B. mit dem Aufruf eines eigenen Programms), dann wird der nachfolgend ausgeführte Programmcode mit denselben Rechten ausgestattet, über die das kompromittierte Programm verfügte. Und damit kristallisieren sich die Programme heraus, auf die es ein Angreifer vornehmlich abgesehen hat: auf Programme, die unter privilegierten Rechten laufen (suid-Bit!). Gelingt ihm dies gar bei einem Programm, das mit Rootrechten ausgeführt wird, könnte der eingeschleuste Code bspw. die Passtwortdatei manipulieren und dem Angreifer vollkommene Macht über den Rechner verschaffen.

Wie viele Programme lagern in Ihrem System? Wie viele davon sind Entwickler-Versionen oder relativ neu? Sie können sich niemals sicher sein, dass die eingesetzte Software keinen Risiken in sich birgt. Für einen Angreifer ist das erste Ziel der Zugang zum Rechner - egal unter welcher Benutzerkennung - um so die Schwächen der Programme für weitere Maßnahmen ausnutzen zu können. D.h. für Sie, als Administrator, dass Sie auch die Passwörter aller Benutzerkennzeichen einer regelmäßigen Kontrolle auf ihre Güte hin unterziehen sollten.

Wie Unix das Passwort ermittelt

Um die Güte abschätzen zu können, muss man die Art und Weiße kennen, wie unter Unix Passwörter erzeugt und gespeichert werden.

Wenn Sie am Login-Prompt Ihr Passwort eintippen, so berechnet eine Funktion crypt die verschlüsselte Zeichenkette zum eingegebenen Klartext. Genau diese Zeichenkette vergleicht Unix mit einer in einer Passwortdatei gespeicherten Zeichenkette. Stimmen beide überein, ist das Passwort gültig (auch wenn modernere Verschlüsselungsverfahren eingesetzt werden, ändert das nichts am hier am Beispiel von crypt demonstrierten Prinzip).

Es mag verwundern, dass das verschlüsselte Passwort in einer Klartext-Datei abgelegt ist. Allerdings ist es extrem aufwändig, vom verschlüsseltem Text auf das Klartextpasswort zu schließen, während die Berechnung der Gegenrechnung (Klartext verschlüsselt) in wenigen Schritten möglich ist. Eine Funktion, die diese Eigenschaft besitz, nennt man daher auch Einwegfunktion. D.h. die Hinrechnung ist einfach, die Gegenrechnung aber unmöglich (es gibt (noch) keinen effizienten Algorithmus). Im Falle der meisten Unix-Systeme, kommt zum Verschlüsseln der Data Encryption Standard (DES) zum Einsatz.

Beispiel: Ich stelle Ihnen die Aufgabe die Primzahlen 113*119 ohne Zuhilfenahme eines Taschenrechners zu ermitteln. Sicherlich kein Problem. Die Gegenrichtung wäre, wenn ich Sie beauftrage, die Primfaktoren der Zahl 13447 zu finden. Für ein Computerprogramm ist das ein Pappenstil, aber Sie werden eine zeitlang darüber brüten. Wählen Sie nun anstatt dreistelliger Primzahlen welche mit 10000 Ziffern, so wird auch ihr Gigahertz-Prozessor ein paar Jahre am Limit werkeln...

Wie sicher ist das Passwort?

Sie könnten jetzt meinen, der DES wäre so ausgeklügelt, dass vom verschlüsselten Text niemals auf den Klartext geschlossen werden könne. Sicher ist die Aussage richtig, wenn Sie mit »darauf schließen« die Anwendung einer Berechnungsvorschrift meinen.

Aber der Hacker geht anders vor. Er nimmt ein elektronisches Wörterbuch, verschlüsselt der Reihe nach jedes enthaltene Wort und vergleicht das Resultat mit dem verschlüsselten Vorbild. Als nächstes kodiert er alle Wörter rückwärts, dann modifiziert er die Klein- und Großschreibung, lässt verschiedene Wörter kombinieren, baut Ziffern und Sonderzeichen ein... Klar, dass er ein Programm verwendet, das all die Modifikationen nach einem bestimmten, der menschlichen Logik nachgeahmten Schema vornimmt. Die heutigen PC's verschlüsseln bis zu mehreren Millionen Wörter binnen einer Minute! Wetten, dass die Trefferquote ganz akzeptabel ist?

Aber ganz so einfach ist es dann doch nicht mehr, da die verschlüsselten Passwörter in aktuellen Distributionen wohl kaum noch in der Datei /etc/passwd zu finden sind, sondern meist die shadow-Suite zum Einsatz gelangt Das Passwort steht nun in der Datei /etc/shadow, die nur noch für Root lesbar ist. Damit ist ein Angreifer am Lesezugriff auf die Shadow-Datei interessiert. Um hier seine Tricks ausspielen zu können, benötigt er Zugang zum System. Womit wir wieder beim Passwortgebahren der »normalen« Benutzer wären...

Der sicherste Weg, schwache Passwörter zu vermeiden, ist, sie von vornherein auszuschließen.

Die Programmpakete zur so genannten proaktiven Passwortprüfung liegen den hier beschriebenen Distributionen nicht bei. Programme wie »anlpasswd«, »npasswd« und »passwd+« sind ein Ersatz für »passwd« und prüfen das vom Benutzer eingegebene Passwort nach bestimmten Regeln (Telefonnummern, Passwortlänge, Groß- und Kleinschreibung, Wörterbuchlisten...) und lehnen es ggf. ab.

Programme, die die verschlüsselten Passwörter in Passwortdateien verifizieren, finden Sie im Lieferumfang fast aller Distributionen. crack und die zugehörigen Wortlisten sind die traditionellen Bestandteile eines Passwortprüfsystems. Nachfolgend möchten wir auf das moderne (und zumindest der SuSE-Distribution beiliegende) »John the Ripper« eingehen.

John the Ripper

John vermag mit verschiedenen Verschlüsselungsschemen umzugehen, u.a. mit DES, Blowfish, MD5 und WinNT LM Hashes.

Des Weiteren versteht es verschiedene Modi:

• Wortliste: Es wird versucht, das Passwort anhand einer Wortliste und optionaler Regeln zu entschlüsseln. Solche Regeln können Buchstabendreher, Kombinationen aus Groß- und Kleinschreibung, zusammen gesetzte Wörter usw. beinhalten. Die maximal zulässige Passwortlänge kann angegeben werden.
• Einfacher Modus: John überprüft das Passwort gegen das Nutzerkennzeichen, Informationen des GECOS-Feldes und »verbreitete« Passwörter (aus Datei /var/lib/john/password.lst)
• Inkrementeller Modus: Alle erdenklichen Zeichenkombinationen werden getestet. Die Passwortlänge kann wiederum beschränkt werden. Mit dieser Methode kann jedes Passwort entschlüsselt werden - vorausgesetzt, man bringt die nötige Geduld mit;-)
• Externer Modus: Hierbei handelt es sich um eine Schnittstelle, die den Einsatz anderer Crackmethoden ermöglicht. Auf diesen Modus soll nicht weiter eingegangen werden.

Einfacher Modus

Zur Demonstration wurden drei Accounts in die Passwortdatei aufgenommen:

• »user1« mit dem passwort »Nobody«
• »user2« mit dem Passwort »2resu«
• »user3« mit dem Passwort »foobar«

john wird im einfachsten Fall mit dem Namen der zu prüfenden Passwortdatei aufgerufen. Im Beispiel schränken wir die Suche auf die oben genannten Benutzerkennzeichen ein.

Binnen Bruchteilen einer Sekunde wurden »foobar« und »2resu« gecrackt. »Nobody« ist mit dieser einfachen Methode nicht beizukommen. Durch Eingabe von [Ctrl][C] wird »john« abgebrochen; den Status der Bearbeitung speichert »john« in einer Datei »john.pot«. Durch Eingabe von:

wird an der Abbruchstelle mit der Suche fortgefahren.

Wortlistenmodus

Die Stärke des Modus hängt zum einen von den verwendeten Wortlisten (Textdatei mit einem Wort pro Zeile) und zum anderen von den Regeln der Datei »john.ini« ab. Wir setzen die Wortlistenprüfung auf das Passwort von »user1« an:

Das - zugegeben recht simple - Passwort entdeckte »john« nach 0.04 Sekunden.

Inkrementeller Modus

Die Laufzeit von »john« ist unbegrenzt. Im inkrementellen Modus läuft es, bis das letzte Passwort erkannt oder der Vorgang explizit abgebrochen wurde. Bei Verwendung dieser Prüfart ist es deshalb ratsam, die Suche mit verringerter Priorität zu starten, um die »normale« Arbeit mit dem System nicht auszubremsen. Das nachfolgende Beispiel startet »john« mit einem »Nicelevel« von 20:

Regelmäßige Prüfung

Es spricht nichts dagegen, hin und wieder die Passwortsicherheit im System zu überprüfen. Mit entsprechendem Nicelevel gestartet, stört der Testlauf die tägliche Arbeit nur unmerklich. john kann jederzeit abgebrochen (z.B. wenn die Systemlast einen bestimmten Schwellwert übersteigt) und im letzten Zustand gestartet werden. Ein nettes Skript ist das dem Paket beiliegende mailer (liegt meist unter /var/lib/john), das automatisch Benutzer mit schwachem Passwort per Mail zum Wechsel auffordert.

Dateischutz

Unter Unix geht der Schutz der Dateien mit den Zugriffsrechten Hand in Hand. Zu liberale Rechte ermöglichen das Lesen von vertraulichen Informationen, das Modifizieren von Daten oder gar das Implementieren von trojanischen Pferden.

SUID - Mit den Rechten des Eigentümers

Programme, die das suid-Flag gesetzt haben, waren (und sind) potentielle Sicherheitslöcher. Leider ist es nach wie vor zwingend erforderlich, dem Benutzer Rootrechte beim Start von Programmen wie »passwd« einzuräumen (sonst könnte niemand sein Passwort ändern, weil die Passwortdatei nur für Root schreibbar ist), aber es finden sich in den meisten Installationen derartige Programme, die einfach mit der Standardinstallation auf der Platte landeten, aber niemals benötigt werden.

Als Systemadministrator gilt es, solche Programme aufzufinden und - bei Nichtgebrauch - von der Platte zu entfernen.

Die nachfolgende Anwendung des Kommandos find findet alle Programme, die das suid-Bit (Eigentümer, Gruppe) gesetzt haben:

Aus der Liste gilt es nun, die Programme heraus zu finden, die nicht benötigt werden. Hier hilft in erster Linie wohl nur ein Schmökern der Literatur, was es mit dem Kommando so auf sich hat. Hat man seine Kandidaten zusammen, sollte man sich vor der Deinstallation noch vergewissern, dass das Kommando nicht von anderen Kommandos/Paketen benötigt wird. Dazu sucht man zunächst das Paket, indem das Programm enthalten ist und fragt nachfolgend die Abhängigkeiten ab (im Beispiel werden RPM-Pakete verwendet):

Anmerkung: Ist man sich nicht absolut sicher, ob das eine oder andere Programm nicht vielleicht doch benötigt wird, so kann man das »suid«-Flag auch entfernen. Anschließend werden nur noch der Besitzer bzw. die besitzende Gruppe sinnvoll mit dem Kommando arbeiten können.

Die »richtigen Rechte«

Was als kritisch erachtet wird, liegt letztlich im Ermessen des Administrators. Rechte, die leicht zu verifizieren sind, sind:

• Dateien mit Schreibrechten für »Alle«
• Homeverzeichnisse mit Schreibrechten für »Alle«
• Konfigurationsdateien mit Schreibrechten für »Nicht-Root-Gruppen«
• Leserechte auf sicherheitsrelevante Dateien, z.B. Mailboxen, Protokolldateien

Bei neu installierten Paketen kann man davon ausgehen, dass die voreingestellten Rechte in irgend einer Art und Weise sinnvoll gewählt sind. Häufig modifiziert man im Laufe der Zeit die Rechte bestimmter Dateien und noch häufiger entfallen dem Gedächtnis die getroffenen Modifikationen. Zum Glück sind die Rechte in den Paketen selbst gespeichert und lassen sich problemlos rekonstruieren:

Aufspüren modifizierter Dateien

Auf Anhieb fallen einem die zu jeder Datei gespeicherten Modifikationszeiten ein. Doch leider sind diese ebenso vertuschbar wie die Dateigröße. Der einfache Ansatz, das Dateisystem nach Dateien mit diesen Parametern zu durchsuchen, stellt die Integrität keinesfalls sicher (zumindest falls ein Profi-Cracker am Werk war).

Neben Werkzeugen wie Tripwire, Hobglobin, sXid u.a, die leider keiner Distribution beiliegen, kann hier eine Bestandsaufnahme des System Abhilfe schaffen. Da die MD5-Verschlüsselung unterdessen allgemein verfügbar ist, kann zu jeder Datei ein MD5-Fingerabdruck erzeugt werden. Speichert der Administrator Dateiname und Fingerabdruck in einer separaten Datei (außerhalb des Dateisystems!), so kann jederzeit die Unversehrtheit überprüft werden:

Das obige Schema auf alle Dateien anzuwenden, scheitert wohl an der damit verbundenen Aktualisierung der »Datenbank«. Zumindest verlangt sie eine manuelle Kontrolle, ob die Änderung rechtens war.

Unveränderbare Dateien

Es gibt sicherlich zahlreiche Dateien, deren Inhalte sich niemals oder nur sehr selten ändern. Warum sollte man diese nicht als »nicht änderbar« markieren? Das Dateisystem ext2 hält hierfür das Konzept der Dateiattribute bereit. Informationen zum Setzen und Löschen solcher Attribute findet der interessierte Leser im Abschnitt Zugriffsrechte.

Systemschutz

Was nützt die sicherste Konfiguration, wenn jederman das System starten oder herunterfahren darf? Die sicherste Methode, Gefahren durch Cracker aus dem Weg zu gehen, wäre, den Rechner in einem gesicherten Raum zu installieren und auf jegliche Netzwerkverbindung zu verzichten. Aber in welchen Situation ist das schon realisierbar?

Nehmen wir also für die folgenden Aussagen an, dass der potentielle Übeltäter legitimen Zugang zu Ihrem Rechner erhält. Wie könnte er meine Sicherheitsstrategie hintergehen und wie schütze ich mein System davor?

Zugang zum System

Auch wenn Sie die kuriosesten Passwörter schlechthin verwenden, so nützt es gar nichts, wenn Sie nicht schon Möglichkeiten des Rechners außerhalb ihres Betriebssystems schützen.

Als erstes sollten Sie sich vergewissern, dass tatsächlich nur die vorgesehenen Betriebssysteme auf Ihrem Rechner bootbar sind. Stellen Sie also im BIOS die Bootreihenfolge so ein, dass ein Start von einem Wechselmedium (CDROM, Floppy) ausgeschlossen wird. In dem Zusammenhang sollten Sie das Passwort im BIOS aktivieren. Da dieses keinesfalls sicher ist (manche BIOS-Implementierungen kennen eine Art Super-Passwort), sollte in kritischen Bereichen die Bootfähigkeit solcher Geräte deaktiviert werden. Entweder hängen Sie das CDROM/Floppy an einen Controller, von dem nicht gebootet werden kann oder sie bauen es ganz aus.

Die nächste Option steht Ihnen bei Verwendung von Bootmanagern wie Lilo oder Chos offen. Diese ermöglichen den Zugang zu einzelnen Betriebssystemen über ein Passwort zu schützen.

Haben Sie mehrere Betriebssysteme parallel installiert, so stellen Sie sicher, dass wichtige Partitionen des einen System aus dem anderen heraus nicht sichtbar sind. Solche Partitionen sollten niemals vom »normalen« Anwender gemountet werden können, eventuell kann die Unterstützung nicht benötigter Dateisystemtypen aus der Konfiguration entfernt werden. In dieser Hinsicht sind leider alle Windows-Betriebssysteme eine große Gefahr, da von diesen aus jeder Nutzer mit entsprechenden Programmen (bspw. explore2fs) Zugriff auf Linuxpartitionen erlangen kann!

Herunterfahren des Systems

Das Booten einer Unix-Workstation bleibt wohl immer dem Administrator vorbehalten. Da Linux aber zunächst für die i368 Architektur - also für Heim-PCs und Heimanwender - entwickelt wurde, existiert mit dem »Affengriff« [Ctrl][Alt][Del] eine jedem Benutzer zugängliche Methode, den Rechner zu booten.

Verhindern können Sie dieses, wenn Sie die entsprechende Zeile aus der Datei /etc/inittab entfernen:

Die Pfadvariable

Immer wieder wundern sich Linux-Neulinge, warum die Shell beim Start eines Kommando verärgert reagiert:

Der Grund wird sofort klar, wenn man sich den Inhalt der Shellvariablen PATH betrachtet:

Jeweils durch den Doppelpunkt getrennt, enthält die Variable alle Verzeichnisse, in denen die Shell nach einem Kommando sucht (das Kommando ist in unserem Fall kein Alias, built-in oder Funktion). Das aktuelle Verzeichnis ist nicht enthalten!

Die Reihenfolge der Pfadangaben in PATH entspricht der Suchreihenfolge der Bash. Existiert z.B. ein Kommando »rm« unterhalb von »/usr/local/bin« und in »/bin«, so wird immer ersteres ausgeführt (es sei denn, /bin/rm wird mit vollständigem Pfad angegeben).

Vorsicht mit »./«!

Aus reiner Bequemlichkeit werden die meisten Anwender ihre Pfadvariable dahin gehend anpassen, dass das aktuelle Verzeichnis mit berücksichtigt wird. In der Bash ließe sich das wie folgt realisieren:

Gibt es einen funktionellen Unterschied zwischen den beiden Angaben? Ja! Die erste Angabe ist dringend zu vermeiden!

Fallstudie

Früher oder später befindet sich jeder Benutzer einmal im Verzeichnis /tmp. Dieses Verzeichnis hat die Eigenschaft, dass jeder seine (temporären) Daten darin ablegen darf. Überlegen Sie sich, was passieren würde wenn sie das Kommando »rm -r .my_temp_dir« aufrufen, jemand aber folgendes Skript unter diesem Namen in »/tmp« abgelegt hat?

Pfutsch sind all die Daten, da das Programm mit ihren Rechten ausgestattet wurde!

Die Alternative, den aktuellen Pfad als letzten zu betrachtenden Pfad anzufügen, schützt in den meisten Fällen. Aber gerade wer des öfteren an verschiedenen Rechnern arbeitet, wird automatisch Kommandos aufrufen, die womöglich gar nicht installiert sind. Er tut es, weil er das Kommando von einer anderen Umgebung her gewöhnt ist. Sicher wäre es Zufall, wenn just dieses Kommando sich als »trojanisches Pferd« enttarnen würde, aber es ist genauso Zufall, dass ausgerechnet Ihr Rechner Ziel eines Crackers wird.

Die oben beschriebenen Szenarien sind der Grund, warum zumindest die Pfadvariable des Administrators niemals das aktuelle Verzeichnis einschließt.

Restricted Shells und die Pfadvariable

Haben Sie den Zugang für einen Benutzer auf eine restricted Shell beschränkt, so darf die PATH-Variable für diesen Benutzer niemals das aktuelle Verzeichnis enthalten.

Die Problematik mag einem gar nicht bewusst sein, darf der Benutzer doch ohnehin in einer restricted Shell sein Homeverzeichnis nicht wechseln. Verfügt er jedoch über einen Editor (bspw. vi) und befindet sich in seinem Heimatverzeichnis eine ausführbare Datei bzw. darf er »chmod« verwenden, so ist folgendes Szenario realisierbar:

1. Der Benutzer startet den Editor
2. Der Benutzer lädt eine Shell in den Editor (im vi »:r /bin/bash«)
3. Der Benutzer schreibt den Inhalt des Editors in die ausführbare Datei (im vi »:w my_script«)
4. Der Benutzer startet »my_script«

Der Benutzer verfügt nun über eine "normale" Shell!

Ressourcen beschränken

So genannte Denial of Service-Angriffe zielen darauf ab, die Hard- und Software eines Rechners auf irgend eine Art und Weise zu beeinträchtigen. Im Netzwerkbereich ist es nach wie vor ein beliebtes Angriffsziel, durch zeitgleiche massive Zugriffe auf irgend welche Server, einen Ausfall dieser zu provozieren. Eine nicht minder schwerwiegende Situation können auch lokale Benutzer herauf beschwören, indem sie - wir müssen ihnen nicht einmal eine Absicht unterstellen - die beschränkten Ressourcen (Rechenleistung, Plattenplatz, geöffnete Dateien, usw.) übermäßig beanspruchen, so dass andere Aufgaben langsamer oder überhaupt nicht mehr erledigt werden.

Je nach Art der Ressourcen lassen sich gezielt Schranken fest setzen, die ein »normaler« Benutzer keinesfalls übertreten kann. Plattenplatz kann jedem Benutzer mittels den nachfolgend beschriebenen Quotas zugeteilt werden; andere Limits verwaltet das bash-interne Kommando ulimit.

Eine weitere Variante der Ressourcen-Zuteilung wird mit dem Einsatz von PAM ermöglicht.

Quotas

Die Möglichkeiten der Befugnisverteilung sind weitreichender, als es das Benutzer- und Gruppenkonzept mit den Zugriffsrechten vermögen.

Im folgenden Abschnitt lernen Sie kennen, wie sie den Anwendern ein bestimmtes und beschränktes Kontingent an Plattenplatz zur Verfügung stellen. Somit halten Sie die Benutzer an, nicht allzu verschwenderisch Datenschrott in ihren Verzeichnissen zu sammeln. Der Bedarf an Speicherkapazität wird kalkulierbar und ein volles Dateisystem wird nicht so schnell Ihr System in die Knie zwingen. Leider unterstützt das Reiserfs keine Quotas.

Quota- Voraussetzungen

Vorraussetzung ist neben dem installierten Paket die Unterstützung von Quotas durch den Kernel:

Abbildung 1: Quota-Option im Kernel

Quotas auf einem Dateisystem einrichten

Das weitere Vorgehen werden wir anhand eines Beispiels erläutern. Zwar wird das von uns gewählte Beispielmedium Diskette aus praktischen Gründen niemals Gegenstand von Quota-Vergaben sein; aber als Strickmuster sollte es durchaus dienlich sein. Für die weiteren Schritte gehen wir davon aus, dass ein ext2-Dateisystem auf der Diskette vorhanden ist.

Ein Dateisystem, auf dem Quotas aktiv sein sollen, muss beim Mounten zusätzlich mit den Optionen usrquota (Quotas auf Benutzerebene) und grpquota (Quotas auf Gruppenebene) versehen werden. Da Quotas sicher erst auf permanent gemounteten Medien einen Sinn ergeben, sollten diese Optionen in der /etc/fstab Aufnahme finden:

Zum Nachvollziehen der folgenden Schritte muss das Dateisystem gemountet sein (ggf. als Root »mount /floppy« aufrufen). Jetzt geht es an das Einrichten der für die Ressourcenverteilung wichtigen Dateien quota.user und quota.group:

Root sollte Eigentümer beider Dateien sein und als Einziger Rechte darauf besitzen.

Eine Überprüfung der bisherigen Vorgänge kann zu diesem Zeitpunkt nicht schaden. Hier gelangt quotacheck zum Einsatz, das entweder die von Quota betroffenen Dateisysteme aus der Datei /etc/fstab betrachtet oder das auf der Kommandozeile angegebene Device. Ein Testlauf über unser Dateisystem auf der Diskette würde - falls es das einzige Dateisystem mit Quotas ist - folgende Ausgaben hervorrufen:

Die Optionen bewirken dabei (wenn nicht anderes angegeben, verwenden die nachfolgend augführten Kommandos dieselben Optionen mit identischer Bedeutung):

Zeigte obiger Kommandoaufruf keinerlei Fehlermeldungen, steht dem Aktivieren der Quotas nichts mehr im Wege:

Die beiden letzten Schritte sollten zukünftig bei jedem Systemstart ausgeführt werden. Die sauberste Lösung ist, beide Aufrufe in ein Runlevelskript aufzunehmen. Beim Herunterfahren sollten Quotas deaktiviert werden. Der folgende Aufruf findet am besten im selben Runlevelskript seinen Platz:

Zuweisung der Schranken

Das An- und Abschalten allein nützt noch gar nichts, solange der Administrator den Plattenplatz noch nicht zugeteilt hat. Er bedient sich hierzu des Kommandos edquota. Sollen nun Quotas eines (oder mehrerer) Benutzer editiert werden, so ist die Option -u mit anschließendem Benutzernamen (oder Liste der Namen) zu wählen:

Wer sich bislang dem Editor vi versagte, sollte sich die Grundlagen dessen Bedienung schleunigst aneignen oder zuvor die Shellvariable »EDITOR« mit dem von ihm beherrschten Instrumentarium belegen.

Die Beschränkung des verfügbaren Speicherplatzes geschieht nun auf zwei Arten:

1. Beschränkung des Gesamtspeicherplatzes (blocks; in kByte)
2. Beschränkung der maximalen Anzahl von Dateien (inodes)

D.h. aus Sicht des Benutzers (bzw. einer Gruppe) können Anforderungen für neuen Speicherplatz fehlschlagen, weil entweder zu viele Dateien angelegt wurden oder die Summe der einzelnen Dateigrößen die maximal zulässige Speicherkapazität überschritten hat.

Der Administrator setzt nun die Soft- und Hardlimits, wobei letztere auf keinen Fall überschritten werden dürfen. Dies impliziert, dass die Angabe des Softlimits kleiner oder gleich der des Hardlimits sein muss.

Übersteigt der verbrauchte Speicherplatz eines Benutzers das Softlimit, so darf er eine gewisse Zeit lang über die Ressourcen verfügen, sofern sie noch unterhalb des Hardlimits liegen. Die Zeitspanne legt Root mit der Option -t fest:

Im Beispiel wurden 7 Tage fest gelegt; die Zeit kann aber feingranularer definiert werden (mit »seconds« auf Sekundenbasis).

Quotas auf Gruppenbasis werden analog definiert (Option »-g«); wir überlassen die Schritte dem Leser und kommen zum abschließenden Test (die Ausgabe entspricht dem Stand nach dem weiter unten exemplarisch ausgeführten »dd«-Kommando):

Hinweis: Um ein und dieselben Quota-Einstellungen für mehrerer Benutzer fest zu legen, editiert der Administrator den Eintrag für einen Benutzer und verteilt diesen mit nachfolgendem Kommandoaufruf auf die anderen:

Anzeige des aktuellen Status

Jeder Benutzer kann zu jeder Zeit mit Hilfe des Kommando quota Auskunft über den ihm verfügbaren Speicherbereich erlangen:

Zum Abschluss provozieren wir einen Fehler, indem wir eine »zu große« Datei erzeugen:

Pluggable Authentication Modules

Flexible Benutzerauthentifizierung

Wenn Sie in Ihrem System das Passwortverhalten vom ursprünglichen »Speichere das verschlüsselte Passwort in der passwd« auf die »Verwende die Shadow-Suite« ummünzen wollten, so war es nicht mit dem einfachen Ersatz des Programms »passwd« und Anlegen der Datei »shadow« getan. Nahezu jedes Programm im System, das eine Authentifizierung des Benutzers vorsieht, musste in der neuen Variante installiert werden. Eine Variante, die den Mechanismus der Shadow-Passwörter beherrscht.

Kurzum: Eine Anpassung an einen neuen Authentifizierungsprozess zog weite Kreise, die kaum mehr manuell durchzuführen waren. Zum Glück schnürten die Distributoren ein diesbezügliches Paket, sodass das Einspielen dessen alle notwendigen Änderungen transparent erledigte.

Nun schreitet die Technik immer weiter fort und bisherige Passwort-Authentifizierungs-Modelle sehen sich durch so genannte Brute-Force-Angriffe massiv gefährdet. Schnelle Rechner oder Rechnerverbunde sind durchaus in der Lage, durch systematische Suche im gesamten Schlüsselraum binnen vertretbarer Zeit (Tage) jedes mittels herkömmlichen DES kodierte Passwort zu knacken. Dennoch ist der Faktor Mensch die Achillesferse eines jeden Passworts.

Neue Authentifizierungsverfahren wie Einmail-Passwörter, biometrische Zugangskontrollen oder Chipkarten ersetzen schon heute in sicherheitskritischem Umfeld die früheren Passworte. Selbst kombinierte Verfahren finden durchaus Anwendung.

Es galt nun, Unix für derartige Methoden zugänglich zu machen. Der Ansatz analog zum Shadowpasswort mit seinen angepassten Programmen wäre zwar machbar gewesen, hätte aber dessen Probleme nicht beseitigt. Ein andersartige Authentifizierung hätte zu tiefgreifenden Eingriffen im System geführt. Die Firma SUN entwickelte die Pluggable Authentication Modules. Hintergrund ist die strikte Trennung aller authentifizierenden Programme vom eigentlichen Verfahren. Die Umsetzung ist denkbar einfach. Anstatt jedes Programm starr gegen eine Authentifizierungsroutine zu linken, kennt das Programm nur noch die Schnittstellen. Die Authentifizierung wird durch Module einer Bibliothek realisiert. Und welches Modul wann zum Einsatz gelangt, ist hochgradig konfigurierbar. PAM wird vermutlich eines Tages die antiquaren Verfahren in die Geschichtsbücher verbannen.

Die Konfigurationsdateien

SUN's Implementierung konfigurierte PAM in einer einzelnen Datei /etc/pam.conf. Aufgrund des enormen Umfangs dieser Datei splittete man in Linux diese in einzelne Einheiten auf, die die Authentifizierung für jeweils einen Dienst beschreiben. Diese Dateien tragen den Namen des Dienstes, den sie konfigurieren und finden sich unterhalb des Verzeichnisses /etc/pam.d/:

other ist kein eigenständiger Dienst, sondern kommt immer dann zum Einsatz, wenn für einen Dienst, der auf die PAM-Bibliotheksfunktionen zurück greift, keine eigene Konfigurationsdatei existiert.

Um kompatibel zu SUN's PAM zu bleiben, kann die Konfiguration unter Linux dennoch in der Datei /etc/pam.conf erfolgen. Diese wird allerdings ignoriert, sobald das Verzeichnis /etc/pam.d existiert.

Eine zu den Dateien in /etc/pam.d äquivalente Datei pam.conf müsste somit alle Zeilen der Dateien aus /etc/pam.d enthalten, wobei jeder Zeile der Namen des Dienstes voransteht. Wir diskutieren nachfolgend die Konfiguration anhand der Datei /etc/pam.d/login. Beachten Sie, dass einige Einstellungen die Vorgaben aus der Datei /etc/login.defs überschreiben.

Jede Zeile einer solchen Datei besteht offensichtlich aus 3-4 Feldern. Das erste Feld beschreibt den Authentifizierungstyp, beim zweiten handelt es sich um ein Kontrollflag. Feld Nr. 3 beinhaltet den Namen des Moduls (eventuell mit vollständigem Pfad). Das optionale 4. Feld kann weitere Argumente enthalten.

Die Programmierschnittstelle

Jedes Programm, das die Möglichkeiten von PAM zu nutzen gedenkt, muss entsprechende Aufrufe tätigen. Zunächst muss ein Programm PAM initialisieren. Vor Ende des Programm gehört es zu guten Programmierstil, die reservierten Ressourcen wieder frei zu geben, sodass die PAM-Funktionsaufrufe in folgenden Rahmen eingebettet sind:

Ein Programm wie login wird nun mit dem Aufruf von pam_authenticate(...) den Start aller Einträge vom Typ auth veranlassen. Die Reihenfolge entspricht den »auth«-Zeilen der Konfigurationsdatei, wobei das Verhalten im Fehlerfall durch die Kontrollflags beeinflusst wird.

Ist »auth« erfolgreich durchgelaufen, wird login mit dem Funktionsaufruf pam_acct_mgmt(...) fortfahren, womit der Reihe nach die »account«-Einträge abgearbeitet werden.

Die Sitzung schließlich wird login mit pam_open_session(...) beginnen und mit pam_close_session(...) beenden. Jeder Aufruf führt zur Bearbeitung der unter "session" aufgeführten Module.

Mit »password« beginnende Zeilen rufen PAM-basierte Programme auf, die die Authentifzierungs-Token ändern (i.A. ein Passwort). Ein Kommando wie passwd beinhaltet zu diesem Zweck den Funktionsaufruf pam_chauthtok(...).

passwd ist somit ein Beispiel dafür, dass ein auf PAM zugreifendes Programm nicht alle Authentifizierungstypen brücksichtigen muss.

Zusätzliche Konfigurationsdateien

Anstatt die zahlreichen Argumente zu einem Modul in jeder Zeile explizit anzugeben, kann für einige Module der Satz voreingestellter Argumente in Konfigurationsdateien niedergeschrieben werden. Diese liegen unter /etc/security: