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.
SYN-Cookies können eingesetzt werden, um SYN-Flood-Angriffe zu abzuschwächen oder zu verhindern.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Es kann das Hinzuladen neuer Kernel-Module im Kernel unterbunden werden, als weiterer Schutz gegen Kernel-Rootkits.
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.
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.
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.
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.
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.
Der Zugriff auf die dmesg-Ausgaben kann dem Angreifer potenziell wertvolle Informationen liefern, und kann daher beschränkt werden.
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.
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.
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).
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.
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/
