Zitat
Es gibt ein paar Distros, wie QubeOS & Co., die standardmäßig alles in eine eigene Sandbox packen und die auch die Bootkette im laufenden Kernel fortsetzen, um den Kernel nach außen abzuhärten gegen Angreifer auch über die Boot Phase hinaus.
Geht manches durcheinander. Eine abgesicherte Bootkette um Manipulationen an Kernel oder Bootloader zu verhindern gibt es auch in openSUSE und inzwischen eigentlich so fast überall. Es nennt sich Secure Boot.
QubeOS hat den Sandboxing Ansatz am konsequentesten umgesetzt, aber mit übersichtlichem Aufwand kann man auch in openSUSE einiges tun. Wirf doch mal einen Blick auf Tomoyo. Das ist ein LSM wie AppArmor, aber ist dafür ausgelegt ein ganzes System abzusichern und nicht nur einzelne Programme. Auch nett finde ich Firejail. Das ist ein Sandbox Tool mit vorgefertigten Profilen für über 600 Programme ... im Prinzip wird so mehr oder weniger der komplette Desktop abgedeckt.
Zitat
Vorallem aber frage ich mich, ob man den über Jahre klaffenden Lücken im Kernel mit erweiterten Rechtemanagement, wie AppArmor, begegnen kann um so mit einem zusätzlichen Layer die Sicherheitslücken stopfen kann?
Jein. AppArmor und so weiter errichten in erster Linie Barrieren im Userland, nicht im Kernel selbst. Wenn der Zugriff in /proc, /sys oder /dev eingeschränkt wird, tut man aber auch was für seine Kernel-Sicherheit.
Ganz unabhängig davon gibt es eine ganze Reihe von Einstellungen in /proc/sys und auf der Kernel Befehlszeile, mit denen der Kernel gehärtet werden kann ohne dass er neu kompiliert werden müsste. Der Kernel Befehlszeile empfehle ich zum Beispiel vsyscall=none init_on_alloc=1 hinzuzufügen, insofern keine proprietären Video Treiber verwendet werden außerdem module.sig_enforce. Für Nicht-Softwareentwickler macht lsm=yama,integrity,apparmor jede Menge Sinn.
In /etc/sysctl.d könnte eine gegebenenfalls neu erzeugte .conf Datei folgendes enthalten:
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 1
kernel.kexec_load_disabled = 1
net.core.bpf_jit_harden = 2
vm.mmap_rnd_bits = 32
vm.mmap_rnd_compat_bits = 16
vm.unprivileged_userfaultfd = 0
Zitat
Zum Beispiel könnte man C und C++ Applikationen durch Benutzen von ASLR und eines soliden Löschen-Models absichern. Doch nachdem die Verwendung eines solchen freiwillig ist, scheren sich leider viele große Linux Applikationen immer noch nicht darum.
ASLR ist in allen großen Distributionen obligatorisch, openSUSE eingeschlossen. Ich bezweifle dass du noch eine einzige Binärdatei in openSUSE ohne ASLR finden wirst, und wenn es sie gibt wäre das meiner Meinung nach einen Bugreport wert.