Beiträge von karlaparla

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.

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.

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)

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.

Zitat

Und die von dir genannten Dateien sind in permissions-config, zumindest unter Leap.

... das war hilfreich.

In Tumbleweed ist es tatsächlich genauso. Was sich aber geändert hat ist der Pfad, der ist jetzt nicht mehr /etc sondern /usr/share/permissions

Hallo! Habe Tumbleweed gerade frisch installiert und soweit ich sehe läuft im großen und ganzen alles rund.

Von meinen früheren Experimenten mit openSUSE kenne ich noch die vorgefertigten Sicherheitsprofile mit verschieden restriktiven Dateiberechtigungen. Über das Yast Security Center können diese aktiviert werden (Security Center -> Sichere Dateiberechtigungen verwenden -> Dateiberechtigungen).

Laut Dokumentation beruht diese Funktion auf den Dateien /etc/permissions.easy, /etc/permissions.secure und /etc/permissions.paranoid, aber die fehlen in meiner neuen Installation komplett. Laut zypper se --provides gibt es auch kein Paket das diese Dateien zur Verfügung stellt.

Weiß jemand wo ich die Konfiguration aktuell finden kann? Oder ob der Mechanismus überhaupt noch funktioniert?

Vielen Dank!

Nur der Vollständigkeit halber: Es geht mittlerweile. Man muss allerdings folgendes der Kernel Befehlszeile hinzufügen:

lsm=yama,integrity,apparmor

entweder direkt in /etc/default/grub, oder via Yast (Bootloader Einstellungen -> Kernel Parameter).

Zweiter Diskussionsstrang:

[opensuse-kernel] enable Yama LSM

Bin gespannt was passiert...

Zitat von Berichtigung

Guck lieber erst mal apparmor.
ptrace kann auf jeden Fall damit geblockt werden.

Du hast Recht. Die Funktionen von Apparmor und Yama überlappen sich teilweise. Man kann mit Apparmor für eine einzelne Anwendung ptrace in jede Richtung verbieten, und eigentlich alle Standardprofile machen von dieser Möglichkeit zumindest teilweise Gebrauch.

Das schöne an Yama ist aber dass die Restriktionen automatisch für alle nicht privilegierten Prozesse gelten, und trotzdem die Dinge normal weiterfunktionieren (zumindest in der kleinsten Einstellung).

Ok, Yama ist scheinbar überall in SUSE deaktiviert, nicht nur in Tumbleweed, auch in Leap.

Schätze mal ich werde einen Bugreport erstellen oder auf der Mailinglist posten, und das dann hierher verlinken.

Außer es bremst mich noch jemand in den nächsten Stunden