openSUSE und Kernel absichern

derwunner

Hast du dich denn auch schon mal mit dem "IT-Grundschutz-Kompendium – Werkzeug für Informationssicherheit" des BSI beschäftigt.

Das ist die Basis, die man zum Sichern seiner IT mindestens erfüllen muss/sollte. Ja nach Art der Zertifizierung kommen noch schärfere Vorgaben zum Tragen.

Wenn man bei der Lektüre dieser BSI Schreibstücke nicht genüsslich lächelt, weil man das längst besser umgesetzt hat, sollte man seine Finger von jedem Keyboard lassen.

scnr.

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.

Zum Nachlesen:

https://kernsec.org/wiki/index…ject/Recommended_Settings

https://www.kernel.org/doc/htm…de/kernel-parameters.html

https://www.kernel.org/doc/Documentation/security/Yama.txt (benötigt lsm=yama,integrity,apparmor auf der Kernel Befehlszeile)

Es geht aber nicht nur um die Härtung des Betriebssystems, auch die technische Infrastruktur und vor allem die Daten müssen vor unberechtigtem Zugriff von außen und vor allem von innen gesichert sein. Der größte Feind sitzt nicht vor der Firewall, sondern viel eher dahinter. Auch die Ausfallsicherheit der IT-Infrastruktur muss einen gewissen Standard aufweisen, durch Cluster, USV, etc.

Wenn die IT zusätzlich zur DSGVO auch noch den Bestimmungen des SGB (Sozialgesetzbuch) unterliegt, dann sind alle administrative Änderungen an IT-Systemen, Programmen oder Datenstrukturen oder auch Datenkorrekturen, die aus einem Softwarefehler heraus resultieren, nicht nur der internen Revision sondern auch externen Prüfungen gegenüber lückenlos nachzuweisen. Ansonsten läuft man (bzw. die Vorgesetzten) Gefahr sich juristisch rechtfertigen zu müssen.

Zitat von derwunner

Vielen Dank, aber kann man nicht auch openSUSE mit dem gehärteten Kernel betreiben? Müsste doch auch gehen, oder?

Sicher "geht" das irgendwie. Aber ich denke, das ist gefrickel.

Zitat von Kanonentux

Sicher "geht" das irgendwie. Aber ich denke, das ist gefrickel.

Einfach einen Kernel von woanders zu nehmen wäre zweifellos Gefrikel.

Wenn die Möglichkeiten, die der openSUSE Kernel zur Konfiguration bietet (/proc/sys und Befehlszeile) tatsächlich nicht ausreichen, wäre der logische nächste Schritt den Kernel selbst zu bauen. Das klingt schwieriger als es ist, und das Internet läuft quasi über mit guten Anleitungen zum Thema. Man würde mit dem openSUSE Kernel anfangen, alles weglassen von dem man sicher weiß dass man es nicht braucht, und dann beispielsweise die Einstellungen der ersten oben verlinkten Seite darauf anwenden. Dann hätte man einen Kernel der viel kleiner ist und somit weniger Angriffsoberfläche bietet, der besser randomisiert ist und mehr oder weniger alle verfügbaren Sicherheitsmechanismen nutzt.

Der Preis für den gehärteten Kernel wäre allerdings dass die Geschwindigkeit nach unten geht. Das ist ein allgemeines Problem, das fast immer auftritt.

Zitat von Igel1954

Es geht aber nicht nur um die Härtung des Betriebssystems, auch die technische Infrastruktur und vor allem die Daten müssen vor unberechtigtem Zugriff von außen und vor allem von innen gesichert sein. Der größte Feind sitzt nicht vor der Firewall, sondern viel eher dahinter. Auch die Ausfallsicherheit der IT-Infrastruktur muss einen gewissen Standard aufweisen, durch Cluster, USV, etc.

Absolut.

Und außerdem: Akzeptiert man Sicherheit als Totschlagargument, begibt man sich auf das was man im englischen einen slippery slope nennt, einen glitschigen Abhang. Unten angekommen ist man erst dann, wenn man ein extrem sicheres System hat, das in der Regel ziemlich unkomfortabel zu benutzen ist und mit großem Aufwand administriert werden muss, von der Zeit das alles zu lernen gar nicht zu reden. Natürlich ist daran nichts schlechtes, aber es ist gut vorher zu wissen worauf man sich einlässt

Zitat von Kanonentux

Sicher "geht" das irgendwie. Aber ich denke, das ist gefrickel.

Wlan "geht" nicht (mit Astra "geht" es.) Conky startet nicht (Wird bei Astra nicht angeboten.)

Ich habe alles wieder zurückgefrickelt.