Sicherheit unter Linux

Übersicht Weiter

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 Zurück Anfang Weiter

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:

Einfacher Modus

Zur Demonstration wurden drei Accounts in die Passwortdatei aufgenommen:

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.

root@sonne> john -users:user1,user2,user3 /etc/shadow
Loaded 3 passwords with 3 different salts (Standard DES [24/32 4K])
2resu          (user2)
foobar         (user3)[Ctrl]-[C]
Session aborted

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:

root@sonne> john -restore
Loaded 1 password (Standard DES [24/32 4K])

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:

root@sonne> john --wordfile=/usr/dict/words -rules -users:user1 /etc/shadow
Loaded 1 password (Standard DES [24/32 4K])
Nobody          (user1)
guesses: 1  time: 0:00:00:04 100%  c/s: 15008  trying: Nobleman - Notation

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:

root@sonne> nice -n 20 john -i /etc/shadow
Loaded 2 passwords with 2 different salts (Standard DES [24/32 4K])

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 Zurück Anfang Weiter

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:

root@sonne> find / -perm +6000

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):

root@sonne> rpm -qf /usr/sbin/suexec
apache-1.3.12-97
root@sonne> rpm -q --whatrequires apache-1.3.12-97
kein Paket verlangt apache-1.3.12

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:

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:

# Beispiel anhand des Paketes "bash"
root@sonne> rpm --setperms bash

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:

root@sonne> for i in $(find / -type f -print): do md5sum $i >> database.txt; done

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 Zurück Anfang Weiter

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:

root@sonne> cat /etc/inittab
...
# Wirkung des Affengriffs abschalten:
#ca::ctrlaltdel:/sbin/shutdown -r -t 4 now
...

Die Pfadvariable Zurück Anfang Weiter

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

user@sonne> ls -l doit
-rwxr-xr-x  1   user  users    177 Sep 23 10:52 doit

user@sonne> doit
bash: doid: command not found

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

user@sonne> echo $PATH
/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin: /usr/lib/java/bin:/usr/games/bin:/usr/games: /opt/gnome/bin:/opt/kde/bin:/usr/openwin/bin

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:

user@sonne> export PATH=.:$PATH
# oder
user@sonne> export PATH=$PATH:.

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?

user@sonne> cat /tmp/rm
#!/bin/sh

cd $HOME
/bin/rm -rf *

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 Zurück Anfang Weiter

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 Zurück Anfang Weiter

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:

Quota-Option im 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:

user@sonne> cat /etc/fstab
...
/dev/fd0    /floppy    ext2    defaults,usrquota,grpquota   0    0
...

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@sonne> touch /floppy/quota.user
root@sonne> touch /floppy/quota.group
root@sonne> chmod 600 /floppy/quota.user
root@sonne> chmod 600 /floppy/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:

root@sonne> quotacheck -avug
Scanning /dev/fd0 [/floppy] done
Checked 2 directories and 2 files
Using quotafile /floppy/quota.user
Using quotafile /floppy/quota.group

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

a

Überprüfen der /etc/fstab nach Einträgen usrquota und grpquota

g

Überprüfen der Dateien und Verzeichnisse für eine Gruppe

u

Überprüfen der Dateien und Verzeichnisse für den Benutzer (Voreinstellung)

v

Erweiterte Ausgabe von Informationen (verbose)

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

root@sonne> quotaon -avug
  /dev/fd0: group quotas turned on
  /dev/fd0: user quotas turned on

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:

root@sonne> quotaoff -avug
  /dev/fd0: group quotas turned off
  /dev/fd0: user quotas turned off

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:

root@sonne> edquota -u user
Quotas for user user:
  /dev/fd0: blocks in use: 0, limits (soft = 50, hard = 60)
  inodes in use: 0, limits (soft = 0, hard = 0)

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:

root@sonne> edquota -t
  Time units may be: days, hours, minutes, or seconds
  Grace period before enforcing soft limits for users:
  /dev/fd0: block grace period: 7 days, file grace period: 7 days

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):

root@sonne> repquota -a
                        Block limits               File limits
User          used    soft    hard  grace    used  soft  hard  grace
root    --      14       0       0              4     0     0
users   --      60       0       0              2     0     0

                        Block limits               File limits
User          used    soft    hard  grace    used  soft  hard  grace
root    --      18       0       0              4     0     0
user    +-      60      50      60  7days       2     0     0

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:

root@sonne> edquota -p tux newbie sam

Anzeige des aktuellen Status

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

user@sonne> quota
Disk quotas for user user (uid 502):
Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
  /dev/fd0       1      50      60              1       0       0

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

user@sonne> dd if=/dev/zero of=Datei bs=1k count=60
/floppy: write failed, user disk limit reached.
dd: Datei: Der zugewiesene Plattenplatz (Quota) ist überschritten
59+0 Records ein
58+0 Records aus

Pluggable Authentication Modules Zurück Anfang

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/:

user@sonne> ls /etc/pam.d
chfn  chsh  login  other  passwd  ppp  rexec  rlogin  rsh  samba  su

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.

user@sonne> cat /etc/pam.d/login
# Anzuzeigender Text (aus /etc/issue) vor dem Login-Prompt:
auth       required   pam_issue.so issue=/etc/issue

# fontRoot darf sich nur an Konsolen aus /etc/securetty anmelden:
auth       requisite  pam_securetty.so

# Existiert /etc/nologin, darf sich einzig Root anmelden
auth       required  pam_nologin.so

# Setzen von Umgebungsvariablen aus /etc/environment (meist nur bei Debian verwendet)
auth       required  pam_env.so

# Passwort-Abfrage; Null-Passwörter sind erlaubt
auth       required  pam_unix.so nullok

# Ein Benutzer gehört zusätzlich einigen "extra"-Gruppen an (diese Gruppen werden in /etc/security/group.conf fest gelegt)
# auth       optional  pam_group.so


# Zeitgesteuerte Zugangsberechtigungen (definiert in /etc/security/time.conf)
# account    requisite  pam_time.so


# Eingeschränkte Zugangsberechtigungen (definiert in /etc/security/access.conf)
# account    required  pam_access.so


# Standard Un*x Zugangs- und Sitzungsberechtigungen
account    required  pam_unix.so
session    required  pam_unix.so
# Limits (definiert in /etc/security/limits.conf)
# session    required  pam_limits.so


# Informationen zum letzten Login anzeigen
session    optional  pam_lastlog.so

# "Nachricht des Tages" ausgeben (Siehe Datei /etc/motd)
session    optional  pam_motd.so

# Benachrichtigung bei neuer Mail
session    optional  pam_mail.so standard noenv

# Bedingungen an ein Passwort
password   required  pam_unix.so nullok obscure min=4 max=8

# Prüfung neuer Passwörter
#
# password required      pam_cracklib.so retry=3 minlen=6 difok=3
# password required      pam_unix.so use_authtok nullok md5

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.

Authentifizierungstyp

Die 4 Typen sind:

account

Steuert den Zugang zu den Diensten, indem die Berechtigungen für einen Benutzer überprüft werden. Weiterhin können zeitabhängige Zugänge ermöglicht und veraltete Passworte erkannt werden.

Anmerkung: Beim »normalen« (Shadow-)Passwortverfahren entspräche der Schritt der Feststellung, ob ein Benutzer Zugang zum System hat (also sein Benutzerkennzeichen bekannt ist).

auth

Hierbei wird gesteuert, wie der Benutzer sich dem System gegenüber ausweisen muss (Passwort, Fingerabdruck, Spracherkennung usw.).

password

Regelt das Vorgehen beim Ändern des Passworts. Bedingungen an dessen Länge, Komplexität u.a.m. lassen sich spezifizieren.

session

Diese Module werden sowohl zu Beginn als auch bei Beendigung einer Sitzung aufgerufen. Sie dienen zur Protokollierung der Sitzung und/oder zum Setzen von nutzerspezifischen Systemschranken.

Kontrollflag

Das Verhalten beim Scheitern einer Prüfung wird hier fest gelegt. Die zulässigen Schlüsselworte sind:

optional

Es wird versucht, das Modul auszuführen. Das Ergebnis spielt aber keine Rolle für die Auswertung weiterer Module.

required

Die Authentifizierung schlägt fehl, sobald eines der mit »required« gekennzeichneten Module scheitert. Die weiteren Module desselben Typs werden allerdings dennoch abgearbeitet.

requisite

Wie »required«, nur führt das Scheitern der Authentifizierung in einem Modul zum sofortigen Abbruch.

sufficient

Es genügt, wenn ein so gekennzeichnetes Modul erfolgreich durchläuft, um die Authentifizierung als erfolgreich zuzulassen. Weitere Module werden bei Erfolg nicht bearbeitet. Bei Nichterfolg eines »sufficient«-Moduls wird mit dem nächsten Modul fortgefahren, so als wäre das »sufficient«-Modul nicht vorhanden gewesen.

Wenn Sie sich unter Unix auf der Konsole anmelden und ein falsches Benutzerkennzeichen angegeben haben, so werden Sie dennoch zur Angabe eines Passwortes aufgefordert. Eigentlich scheint dies sinnlos, wird einem nicht-existenten Benutzer doch ohnehin der Zugang verwehrt. Aber was ist das erste Ziel eines Crackers? Die Kenntnis der Benutzerkennzeichen auf einem Rechner. Und mit Ausnahme des allgegenwärtigen Root lässt ein gescheiterter Anmeldevorgang keinen Rückschluss zu, ob ein Benutzerkennzeichen existiert (aus diesem Grund wird in manchen Konfigurationen des kdm auf die Anzeige der Benutzer verzichtet).

Im Zusammenhang mit PAM lässt sich das beschriebene Abfrageverhalten realisieren, indem das Benutzerkennzeichen mit »required« versehen wird. Meist wird sogar die Passwortabfrage per »required« vorgenommen, um eine anschließende Protokollierung (»session«) vorzunehmen.

Modul(pfad)

Hier genügt der Name des Moduls, wenn dieses im Verzeichnis /lib/security liegt. Module in anderen Pfaden müssen mit vollständigem Zugriffspfad angegeben werden.

Argumente (optional)

Jedes Modul kann zumeist durch zahlreiche Optionen in seiner Arbeitsweise gesteuert werden, d.h. die hier möglichen Argumente sind stark vom Modul selbst abhängig und in der Dokumentation zu diesem beschrieben (oft befinden sich die Textdateien unter /usr/[share/]doc/[packages/]/pam). In der obigen Beispieldatei legt bspw. nullok des Moduls »pam_unix.so« die Zulässigkeit leerer Passwörter fest. min=4 und max=8 beschränken die Länge eines Passworts und obscure veranlasst einfache Regeln über das Aussehen des Passworts (nicht ausschließlich (Klein)Buchstaben...).

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:

...
pam_start (...);
# PAM-Funktionsaufrufe u.a.m.
pam_end(...);
...

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:

access.conf

Die (auch leere) Datei wird vom Modul pam_access benötigt. Sie ermöglicht eine detaillierte Konfiguration, welchem Benutzer an welchem Terminal der Zugang zum System verwehrt/gestattet wird. Eine Konfigurationszeile besteht aus drei, durch Doppelpunkte getrennten Feldern.

Das erste Feld definiert die folgenden Angaben als Verbot (Minus) oder Erlaubnis (Plus).

Das zweite Feld enthält die Liste der Benutzer, die davon betroffen sind. Neben Benutzerkennzeichnen steht ALL für alle Benutzer, LOCAL für lokale Benutzer und mittels EXCEPT lassen sich Ausnahmen festlegen.

Das dritte Feld umfasst die Quelle des Zugriffs, also den Namen des Terminals, einen Rechnernamen oder -adresse, einen Netzwerknamen, oder -adresse (Domain), sowie ALL und LOCAL bzw. EXCEPT.

Um bspw. die Anmeldung als Root einzig an der lokalen Konsole zuzulassen, ist folgender Eintrag denkbar:

...
- : root : ALL EXCEPT console
...

group.conf

Diese (auch leere) Datei wird vom Modul pam_group benötigt. In Erweiterung der von Gruppen her bekannten Zugriffsrechte vermag ein Benutzer einer Gruppe nur unter bestimmten Voraussetzungen (»zwischen 8 und 18 Uhr«, »wenn er sich im Terminal XXX anmeldet«,...) zugeordnet werden.

Die fünf Felder eines Eintrags sind hier durch Semikola getrennt. Das 1. Feld enthöält eine Liste der PAM-Dienste, für die die Zeile in Frage kommt. Der Name des PAM-Dienstes entspricht häufig dem Namen des Programms, kann aber vom Programm selbst »umgebogen« werden, um den Zusammenhang zwischen Konfigurationsdatei und Dienst zu verschleiern.

Das 2. Feld, die Liste der Terminals, verfügt, dass die Gruppenzuordnung nur erfolgt, wenn der Benutzer sich am betreffenden Terminal anmeldet.

Feld Nr.3 enthält die Liste der Benutzer.

Zu welchen Zeiten die Gruppenzugehörigkeit gestattet ist, schreibt das 4. Feld vor. Die Syntax lautet "TagStartzeit-Endzeit". "Tag" ist ein zweibuchstabiges Symbol, wobei "Mo", "Tu", "We", "Th", "Fr", "Sa" und "Su" für die einzelnen Tage stehen. "Wk" sind die Wochentage Mo-Fr, "Wd" das Wochenende und "Al" steht für "alle Tage". Kombinationen wie "AlMo" oder "WdMo" sind erlaubt. Da im ersteren Fall "Montag" doppelt erfasst ist, wird dieser Tag aus der Liste entfernt, während im zweiten Beispiel der Montag hinzuaddiert wird. Die Start- und Endzeit wird im Format HHMM angegeben (HH-Stunden, MM-Minuten).

Das 5. Feld enthält die Liste der Gruppen, denen ein Benutzer zugeordnet wird, falls alle 4 Bedingungen der vorherigen Felder erfüllt sind.

Das folgende Beispiel ordnet alle Benutzer der Gruppe »games« zu, falls sie sich am Wochenende nach 8.00 Uhr an einem lokalen Terminal anmelden:

...
login;tty*&!ttyp*;*;Wd0800-2400;games
...

limits.conf

Die vom Modul pam_limits benötigte Datei beschränkt die einem Benutzer zur Verfügung stehenden Ressourcen. Die vier Felder werden durch Leerzeichen oder Tabulatoren getrennt.

Das erste Feld legt den/die Benutzer fest, denen die Schranken auferlegt werden. Neben Benutzerkennzeichen, sind die Angabe von Gruppen (»@games«) und Wildcards (»*«) zulässig.

Im 2. Feld darf soft, hard oder ein Minus stehen, je nachdem, ob das Limit zum Abbruch einer Anforderung (hard) oder nur zu einer Warnung (soft) führen soll. Ein Minus wirkt wie »hard«.

Feld 3 ist der Name eines Limits und Nr 4. beinhaltet den zugeordneten Wert.

Wichtige Limits sind data, rss, stack, priority und as, die unmittelbar die Ressourcen beschränken, die ein einzelnes Programm beanspruchen darf. Wie viele Dateien ein Benutzer öffnen darf, besagt nofile und die Anzahl Prozesse, die er starten darf nproc. Verfügbare Prozessorzeit wird in Minuten per cpu angegeben. Wo oft sich ein Benutzer maximal gleichzeitig anmelden darf, beschränkt maxlogins.

...
*          soft    nproc    20
*          hard    nproc    30
ftp        hard    fsize  1024
@games     hard    cpu      20
@users     -       maxlogins 4
...

pam_env.conf

Die Datei wird vom Modul pam_env benötigt und ermöglicht den Export von Umgebungsvariablen. Jede Zeile beginnt mit dem Variablennamen, dem zwei Optionen folgen können. DEFAULT=Wert weist einer Variablen einen default-Wert zu. OVERRIDE=Wert wird verwendet, um diesen voreingestellten Wert zu überschreiben. Als Wert kann auch auf den Inhalt von anderen Variablen zurück gegriffen werden, so setzt die folgende Zeile DISPLAY auf »0.0«, falls die Variable nicht schon gesetzt war. War sie bereits gesettt, bleibt ihr alter Wert erhalten:

...
DISPLAY     DEFAULT="0.0"   OVERRIDE=${DISPLAY}
...

time.conf

Die Datei ist analog zu »group.conf« aufgebaut mit Ausnahme des 5.Feldes, das hier entfällt. Durch diese Konfiguration kann der Zugang zu den PAM-Diensten zeitlich beschränkt werden.

Die Datei wird vom Modul pam_time benötigt.