Obwohl eine Vielzahl von Bugs und auch Sicherheitslücken durch die Unglaubliche komplexität und über 19,5 Millionen Zeilen Code fast garantiert ist, sollen Systeme auch gegen Zero-Day-Exploits gehärtet und abgesichert werden.

Ziel dieses Beitrags soll sein, eine grobe Übersicht über Sicherheitsmechanismen zu geben, welche bereits im Linus-Kernel implementiert werden, oder optional hinzugefügt werden können.

1. SYN-Cookies

SYN-Cookies können eingesetzt werden, um SYN-Flood-Angriffe zu abzuschwächen oder zu verhindern.

2. Möglichkeiten des Dateisystems

Wenn ein modernes Dateisystem sogenannte xattrs oder erweiterte Attribute unterstützt, können dadurch an eine Datei zusätziche Metadaten angehängt werden, beispielsweise Access Control Lists (ACLs).

3. PR_SET_SECCOMP

Einige Systeme unterstützen das Einstellen des Secure Computing (SECCOMP) für einzelne Prozesse, wodurch die Prozesse auf 4 Aufrufe von APIs beschränkt und somit in eine Sandbox gesteckt werden.

4. Trusted Plattform Module

Es handelt sich bei dem TPM um einen Chip, welcher in Systemen eingesetzt werden kann, um Sicherheitsmechanismen von einem potenziell kompromittierten Betriebssystem oder Kernel auszulagern, und in einem externen, vertrauenswürdigen Chip durchzuführen.

5. /proc/$pid/maps Schutz

Weil die genauen Adressen von Speicherbereichen durch den Einsatz von ASLR für einen Angreifer sehr wertvoll sind, schützen moderne Linux-Kernel den zugriff auf die oben genannte Datei.

6. Symlink Einschränkungen

Häufig kommt eine Art von Sicherheitslücken durch Race Conditions vor. Diese besteht darin, dass ein Prozess mit höheren Privilegien einen symlink eines anderen Benutzers folgt. Um diese Art von Time of Check, Time of Use (ToCToU)-Angriff zu verhindern, verhindern einige Systeme, dass Prozesse simlinks in öffentlichen Verzeichnissen folgen, sofern sie nicht vom Ersteller des Prozesses erstellt wurden.

7. ptrace Zugriff

Der Kernel kann, um die Ausweitung einer Attacke eines Angreifers innerhalb des Kontextes eines Benutzers zu verhindern, dass ein ptrace() von einem Prozess auf andere Prozesse, als solche von ihm erzeugten debuggen dürfen.

9. Nullzeigerschutz

In der virtuallen Speicherverwaltung, kann der Nullzeiger innerhalb eines Prozesses eigentlich auf einen belegten Speicherbereich zeigen, der vom Angreifer kontrolliert wird. Hierdurch kann ein Angreifer beliebigen Code von einem anderen Prozess ausführen lassen, wenn der Prozess den Nullzeiger dereferenziert und dieser auf den vom Angreifer kontrollierten Speicherbereich verweist. Eine Möglichkeit von dem Linux-Kernel diese Art von Angriffen weniger schädlich zu machen, indem er verhindert, dass der Nullzeiger von Prozessen unterhalb einer bestimmten Adresse anfägt, weil die unteren Adressbereiche für den Kernel reserviert sind.

10. /dev/mem Schutz

Mit der oben genannten Datei kann physikalischer Zugriff auf den Speicher ermöglicht werden. Der Linus-Kernel kann, um eine Manipulation zu verhindern, erzwingen, dass nur Geräte Zugriff auf den Kernelspeicher erhalten.

11. /dev/kmem deaktivieren

Weil /dev/kmem von Angreifern nicht mehr verbreitet genutzt wird, außer von Angreifern die dort ihre Kernel-Rootkits ablegen, kann der Kernel so eingestellt werden, dass er /dev/kmem komplett deaktiviert und dort geladene Module ignoriert.

12. Blockieren neuer Module

Es kann das Hinzuladen neuer Kernel-Module im Kernel unterbunden werden, als weiterer Schutz gegen Kernel-Rootkits.

13. Nur Lesezugriff für ausführbaren Code im Kernel

Manche Kernel-Rootkits verändern den ausführbaren Code im Kernel, um ihre Aktivitäten zu verstecken. Diese funktionieren jedoch nicht, sobald man den Zugriff auf diese Codebereiche beschränkt. Zudem können die Codebereiche auch so eingestellt werden, dass sie nicht mehr ausführbar sind, so dass die Originaldaten auch niemals als Code interpretiert werden können.

14. Stack-Pufferüberlauf-Schutz

Zufällig gewählte Ganzzahlwerte vor der Rücksprungadresse einer jeden Funktion können als Schutz vor Pufferüberläufen im Kernel-Stack platziert werden.

15. Verbergen von Adressen im Kernel

Normale Benutzer können die Adressen von internen Strukturen im Kernel verbergen, um zu verhindern, dass Angreifer diese ausnutzen können, um ihre Exploits einfach auszunutzen und auf andere Systeme übertragen zu können.

16. Seltene Netzwerkprotokolle unterbinden

Für gewöhnlich werden Module zur Behandlung von Netzwerkprotokollen automatisch bei Bedarf in den Kernel geladen. Da selten genutzte oder alte Protokolle potentielle Sicherheitslücken bergen, kann der Kernel verhindern, dass diese automatisch geladen werden und sie nur auf explizite Anfrage des Benutzers hin laden.

17. syscall Filterung

Zur Limitierung des Schadens, den ein Programm anrichten kann, kann der Zugriff auf syscalls, mit denen System-APIs angesprochen werden, limitiert werden. Dadurch wird das Programm effektiv in einer Sandbox ausgeführt.

18. dmesg Einschränkungen

Der Zugriff auf die dmesg-Ausgaben kann dem Angreifer potenziell wertvolle Informationen liefern, und kann daher beschränkt werden.

19. kexec blockieren

Der aktuell laufende Kernel kann durch kexec während des laufenden Betriebs durch einen anderen Kernel ersetzt werden. Da dadurch von einem Angreifer ein manipulierter Kernel geladen werden kann, kann der Originalkernel diesen Aufruf ignorieren.

20. UEFI Secure Boot

Dieser Mechanismus sorgt dafür, dass nur digital signierte Bootloader beim Systemstart ausgeführt werden können. Das verhindert, dass ein Angreifer den Bootloader manipuliert. Zudem kann jene Verifizierung erweitert werden auf einen digital signierten Kernel, wodurch auch Modifikationen am Kernel erkannt werden können.

21. DEP

DEP ist eine Technik zur Verhinderung von der Ausführung von als nicht-ausführbar markierten Speicherbereichen. Dadurch kann verhindert werden, dass ein Angreifer, der es geschafft hat, Code in den Stack eines Programms zu schreiben, diesen auch ausführen kann, obwohl die betroffene Speicherregion als nicht-ausführbar markiert wurde. DEP kann entweder durch moderne CPUs ermöglicht oder softwareseitig emuliert werden. DEP kann jedoch umgangen werden, indem Angreifer darauf achten, nur Code auszuführen, der in einer als ausführbar markierten Region abgelegt ist. Beispielsweise mit Return-Oriented-Programming (ROP).

22. ASLR

Um ein Umgehen von DEP per ROP zu verhindern, wurde ASLR entwickelt. Hierbei werden Speicheradressen randomisiert, um einen bis dahin deterministischen Angriff, der auf festen Speicheradressen basiert, durch einen probalistischen zu ersetzen, dessen Erfolgschancen vom Zufall abhängen, solange der Angreifer diese Adressen nicht zur Laufzeit herausfinden kann.

23. SELinux

SELinux (Security-Enhanced Linux) ist eine erweiterung des Linux-Kernels, welche auf der Linux Security Modules (LSM)-Schnittstelle aufbaut. Erfunden vom US-Geheimdienst National Security Agency (NSA) implementiert dieses System das Mandatory Access Control (MAC)-Modell, welches die Zugriffsrechte auf bestimmte Systemressourcen steuert.

Quellen:
image.informatik.htw-aalen.de/Thierauf/Seminar/Ausarbeitungen-16WS/Linux.pdf
https://pixabay.com/en/background-security-linux-3d-1900329/