Linus Torvalds
Erreicht ein Angreifer die Codeausführung mit Root-Rechten, kann er seinen Code auf Kernel-Ebene ausführen, indem er beispielsweise den Kernel mit kexec ersetzt oder Speicher über /dev/kmem liest/schreibt. Die offensichtlichste Konsequenz einer solchen Aktivität kann sein
Ursprünglich wurden Root-Einschränkungsfunktionen im Zusammenhang mit der Stärkung des Schutzes beim verifizierten Booten entwickelt, und Distributionen verwenden seit geraumer Zeit Patches von Drittanbietern, um die Umgehung von UEFI Secure Boot zu blockieren. Gleichzeitig wurden solche Einschränkungen aufgrund von nicht in die Hauptzusammensetzung des Kernels aufgenommen
Der Sperrmodus schränkt den Zugriff auf /dev/mem, /dev/kmem, /dev/port, /proc/kcore, debugfs, kprobes Debug-Modus, mmiotrace, Tracefs, BPF, PCMCIA CIS (Card Information Structure), einige ACPI-Schnittstellen und die CPU ein MSR-Register, kexec_file- und kexec_load-Aufrufe sind blockiert, der Schlafmodus ist verboten, die DMA-Nutzung für PCI-Geräte ist eingeschränkt, der ACPI-Code-Import aus EFI-Variablen ist verboten,
Manipulationen an I/O-Ports sind nicht zulässig, einschließlich der Änderung der Interrupt-Nummer und des I/O-Ports für den seriellen Port.
Standardmäßig ist das Lockdown-Modul nicht aktiv, es wird erstellt, wenn die Option SECURITY_LOCKDOWN_LSM in kconfig angegeben ist, und wird über den Kernel-Parameter „lockdown=“, die Steuerdatei „/sys/kernel/security/lockdown“ oder Assembly-Optionen aktiviert
Es ist wichtig zu beachten, dass der Lockdown nur den Standardzugriff auf den Kernel einschränkt, aber keinen Schutz vor Änderungen infolge der Ausnutzung von Schwachstellen bietet. Um Änderungen am laufenden Kernel zu blockieren, wenn Exploits vom Openwall-Projekt verwendet werden
Source: opennet.ru