Kapitel 4. Authentifizierung und Zugriffskontrolle

Hier einige erwähnenswerte Konfigurationsdateien, die von PAM und NSS genutzt werden:

Einschränkungen bei der Passwortauswahl sind über die PAM-Module pam_unix(8) und pam_cracklib(8) implementiert. Diese können über deren Argumente konfiguriert werden.

	Tipp
	PAM-Module verwenden den Anhang ".so" für ihre Dateinamen.

Ein Lightweight Directory Access Protocol (LDAP)-Server erlaubt modernes zentralisiertes Systemmanagement und somit die Administrierung vieler Unix-ähnlicher und nicht-Unix-Systeme über das Netzwerk. Die quelloffene Implementation des Lightweight Directory Access Protocol ist OpenLDAP.

Der LDAP-Server stellt die Konteninformationen auf Debian-Systemen durch die Nutzung von PAM und NSS über die libpam-ldap- und libnss-ldap-Pakete bereit. Verschiedene Aktionen sind nötig, um dies zu aktivieren. (Ich verwende dieses Setup nicht, daher stammen diese Informationen komplett aus zweiter Hand. Bitte beachten Sie das beim Lesen dieses Abschnitts.)

Lesen Sie die Dokumentation in pam_ldap.conf(5) und "/usr/share/doc/libpam-doc/html/" aus dem libpam-doc-Paket sowie "info libc 'Name Service Switch'", bereitgestellt durch das Paket glibc-doc.

Ähnlich zu diesem Verfahren können Sie auch alternative zentralisierte Systeme mit anderen Methoden einrichten:

Dies ist eine bekannte Redewendung am Ende der alten "info su"-Seite von Richard M. Stallman. Aber keine Sorge: der aktuelle su-Befehl in Debian nutzt PAM, so dass man die Erlaubnis zur Nutzung von su auf die root-Gruppe beschränken kann, indem die Zeile mit "pam_wheel.so" in "/etc/pam.d/su" aktiviert wird.

# here are the per-package modules (the "Primary" block)
password	requisite			pam_cracklib.so retry=3 minlen=8 difok=3
password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
password	optional	pam_gnome_keyring.so 
# end of pam-auth-update config

Viele beliebte Transport-Layer-Dienste kommunizieren Nachrichten inklusive der Passwort-Authentifizierung im Klartext. Es ist eine sehr schlechte Idee, Passwörter im Klartext über das wilde Internet zu übertragen, wo es abgehört werden kann. Sie können diese Dienste über "Transport Layer Security" (TLS) oder seinen Vorgänger "Secure Sockets Layer" (SSL) betreiben, um die vollständige Kommunikation inklusive des Passworts über die Verschlüsselung zu schützen.

Die Verschlüsselung kostet CPU-Zeit. Als CPU-freundliche Alternative können Sie die Kommunikation im Klartext lassen und nur das Passwort verschlüsseln; verwenden Sie dazu ein sicheres Authentifizierungsprotokoll wie "Authenticated Post Office Protocol" (APOP) für POP oder "Challenge-Response Authentication Mechanism MD5" (CRAM-MD5) für SMTP und IMAP. (Um E-Mail-Nachrichten über das Internet von Ihrem Mail-Client-Programm zum Mail-Server zu übertragen, ist es derzeit verbreitet, den neuen Message-Submission-Port 587 zu nutzen statt dem traditionellen SMTP-Port 25, um zu vermeiden, dass Port 25 vom Netzwerk-Provider geblockt wird, während Sie sich über CRAM-MD5 authentifizieren.)

Das Secure-Shell-(SSH-)Programm bietet sichere verschlüsselte Kommunikation zwischen zwei nicht vertrauenswürdigen Rechnern über ein unsicheres Netzwerk mittels sicherer Authentifizierung. Es besteht aus dem OpenSSH-Client (ssh(1)) und dem OpenSSH-Daemon (sshd(8)). SSH kann genutzt werden, um mittels der Port-Forwarding-Funktionalität (Port-Weiterleitung) eine unsichere Protokoll-Kommunikation wie POP oder X gesichert durch das Internet zu tunneln.

Der Client versucht, sich selbst über eine Host-basierte Authentifizierung gegenüber dem Server zu identifizieren; dazu können verschiedene Verfahren angewandt werden: Public Key Authentication (über einen öffentlichen Schlüssel), Challenge-Response Authentication (es wird eine Aufgabe gestellt, für die die andere Seite die Lösung liefern muss) oder Passwort-Authentifizierung. Die Nutzung der Public Key Authentication ermöglicht eine Anmeldung aus der Ferne ohne Passwort. Lesen Sie dazu Abschnitt 6.3, „Der Server für Fernzugriff (SSH) und Hilfsprogramme“.

Sogar wenn Sie sichere Dienste wie Secure Shell (SSH) und Point-to-point Tunneling Protocol (PPTP) verwenden, bestehen trotzdem noch Chancen für die Einbrecher mittels Brute-Force-Atttacken zum Erraten von Passwörtern usw. über das Internet. Die Nutzung von Firewall-Richtlinien (mehr dazu in Abschnitt 5.6, „Die Netfilter-Infrastruktur“) zusammen mit den folgenden Sicherheitswerkzeugen kann die Situation weiter verbessern.

Um zu verhindern, dass Leute auf Ihre Maschine mit root-Privilegien zugreifen, müssen Sie folgende Aktionen durchführen:

• physikalischen Zugriff auf die Festplatte unterbinden;

• das UEFI/BIOS abriegeln und verhindern, dass von Wechseldatenträgern gebootet wird;

• ein Passwort für interaktive Sitzungen von GRUB vergeben;

• das Editieren des GRUB-Menüs verhindern.

Mit physikalischem Zugriff auf die Festplatte ist das Zurücksetzen des root-Passworts relativ leicht; dies erfordert folgende Schritte:

1. Bauen Sie die Festplatte in einen PC mit UEFI/BIOS ein, der von CD gebootet werden kann.

2. Booten Sie das System mit einer Rettungs-CD (Debian Boot-Disk, Knoppix-CD, GRUB-CD, …).

3. Binden Sie die root-Partition mit Lese-/Schreibberechtigung ein.

4. Editieren Sie "/etc/passwd" auf der root-Partition und verändern Sie den zweiten Eintrag für das root-Konto, so dass dieser leer ist.

Wenn Sie beim Booten Schreibzugriff auf den GRUB-Menüeintrag für grub-rescue-pc haben (lesen Sie dazu Abschnitt 3.1.2, „Stufe 2: der Bootloader“), ist es mit folgenden Schritten sogar noch einfacher:

Die root-Shell des Systems ist jetzt ohne Passwort zugänglich.

Die einzige vernünftige Software-Lösung, um all diese Bedenken auszuräumen, ist die Verwendung einer Software-verschlüsselten root-Partition (oder "/etc"-Partition) mittels dm-crypt und initramfs (lesen Sie dazu Abschnitt 9.9, „Tipps zur Datenverschlüsselung“). Sie benötigen dann allerdings immer ein Passwort, um das System zu booten.

Das Programm sudo(8) wurde entwickelt, um einem Systemadministrator die Möglichkeit zu geben, Benutzern eingeschränkte root-Privilegien zu gewähren sowie um die Aktivitäten rund um das root-Konto zu protokollieren. sudo benötigt nur das Passwort eines normalen Benutzers. Installieren Sie das sudo-Paket und aktivieren Sie es, indem Sie passende Optionen in "/etc/sudoers" setzen. Konfigurationsbeispiele finden Sie unter "/usr/share/doc/sudo/examples/sudoers" und in Abschnitt 1.1.12, „sudo-Konfiguration“.

Die Art, wie ich sudo auf meinem Einzelbenutzersystem verwende (lesen Sie Abschnitt 1.1.12, „sudo-Konfiguration“), soll mich selbst vor meiner eigenen Dummheit schützen. Ich persönlich denke, dass die Verwendung von sudo eine bessere Alternative zur dauerhaften Nutzung des root-Kontos ist. Der folgende Befehl ändert zum Beispiel den Eigentümer von "irgendeine_datei" in "mein_name":

$ sudo chown my_name some_file

Wenn Sie das root-Passwort kennen (was bei Benutzern, die sich ihr Debian-System selbst installieren, immer der Fall ist), können Sie natürlich jeden Befehl von jeglichem Benutzerkonto aus ausführen, indem Sie "su -c" verwenden.

PolicyKit ist eine Komponente des Betriebssystems zur Kontrolle von systemweiten Privilegien auf Unix-ähnlichen Systemen.

Neuere GUI-Anwendungen sind nicht dafür entwickelt, als privilegierte Prozesse zu laufen. Sie kommunizieren mit privilegierten Prozessen über PolicyKit, um administrative Operationen durchführen zu können.

Auf Debian-Systemen beschränkt PolicyKit solche Operationen auf Benutzerkonten, die der sudo-Gruppe angehören.

Lesen Sie dazu polkit(8).

Aus Gründen der Systemsicherheit ist es eine gute Idee, so viele Server-Programme wie möglich zu deaktivieren. Dies ist besonders für Netzwerk-Server kritisch. Ungenutzte Server, die entweder direkt als Daemon oder über den Super-Server aktiviert sind, müssen als Sicherheitsrisiko angesehen werden.

Viele Programme wie sshd(8) verwenden PAM-basierte Zugriffskontrollen. Es gibt viele Möglichkeiten, um den Zugriff auf Server-Dienste einzuschränken:

Lesen Sie dazu Abschnitt 3.5, „Systemmanagement“, Abschnitt 4.5.1, „Konfigurationsdateien, auf die PAM und NSS zugreifen“ und Abschnitt 5.6, „Die Netfilter-Infrastruktur“.

Der Linux-Kernel hat Sicherheitsfunktionen entwickelt und unterstützt sie immer noch, die in traditionellen UNIX-Implementierungen nicht zu finden sind.

Linux unterstützt erweiterte Dateiattribute, die über die traditionellen UNIX-Attribute hinausgehen (siehe xattr(7)).

Linux teilt die Privilegien, die dem Superuser traditionell zugewiesen wurden, in verschiedene Bereiche auf, bekannt als Capabilities(7), die unabhängig voneinander aktiviert oder deaktiviert werden können. Capatilities sind Attribute, die pro Prozess definiert werden können, und werden seit der Kernel-Version 2.2 unterstützt.

Das Linux Security Module (LSM) Framework stellt einen Mechanismus für verschiedene Sicherheits-Checks bereit, die von neuen Kernel-Erweiterungen abhängig sind. Zum Beispiel:

Da diese Erweiterungen die Privilegien grundsätzlich weiter einschränken, als dies im normalen UNIX-artigen Sicherheitsmodell der Fall ist, können unter Umständen sogar die Superuser-Rechte beschnitten sein. Sie werden aufgefordert, das Dokument zum Linux Security Module (LSM) Framework auf kernel.org zu lesen.

Das Konzept der Linux Namespaces hüllt eine globale Systemressource in eine Abstraktion, die dazu führt, dass es für einen Prozess innerhalb des Namespace so erscheint, als hätte er eine eigene isolierte Instanz dieser globalen Ressource. Änderungen an der globalen Ressource sind für alle Prozesse innerhalb des Namespace sichtbar, nicht aber für andere Prozesse. Seit Kernel-Version 5.6 gibt es 8 Arten von Namespaces (lesen Sie dazu namespaces(7), unshare(1), nsenter(1)).

Mit Stand Debian 11 Bullseye (2021) nutzt Debian die Funktionalität "unified cgroup hierarchy" (a.k.a. cgroups-v2).

Anwendungsbeispiele für Namespaces mit cgroups, die die Isolation von Prozessen sowie die Zugriffskontrolle ermöglichen, sind:

Diese Funktionalitäten können nicht über das Konzept in Abschnitt 4.1, „Normale Unix-Authentifizierung“ realisiert werden! Solche fortgeschrittenen Themen sind allerdings nicht Thema dieses einführenden Dokuments.