1. Ein Quäntchen mehr Sicherheit
Im letzten Beitrag der Artikelserie »Linux härten« hatte ich euch grundlegende Maßnahmen zur Absicherung eines Linux-Systems vorgestellt. Wir haben gelernt: Schon mit einfachen Mitteln kann man ein relativ gutes Sicherheitsniveau erreichen. Luft nach oben ist immer. Allerdings gilt dabei zu bedenken: Je höher das Sicherheitsniveau von eurem Rechner bereits ist, umso mehr Aufwand müsst ihr reinstecken, um einen kleinen Sicherheitsgewinn zu erzielen.
Rufen wir uns an dieser Stelle noch einmal kurz das Ziel der Artikelserie in Erinnerung: Das Ziel besteht in der Minimierung von Risiken, die durch Schwachstellen in Software entstehen. Die bisher vorgestellten Absicherungsmaßnahmen reduzieren generell die Angriffsfläche und erhöhen die Gesamtsicherheit eures Systems – mehr als eine solides Fundament ist das allerdings nicht. Denn all die bisher aufgezeigten Tipps schützen nicht vor sogenannten Zero-Day-Exploits, den Angriffen auf bislang unbekannte Sicherheitslücken.
Es ist also an der Zeit, die Folgen eines Zero-Day-Exploits auf ein Minimum zu begrenzen – das gilt insbesondere für Standardanwendungen wie Webbrowser oder PDF-Reader. Helfen soll uns dabei das Sicherheitsframework AppArmor.
- Sicheres Desktop System – Linux härten Teil1
- Linux Systemhärtung Basis – Linux härten Teil2
- AppArmor – Linux härten Teil3
- Firejail – Linux härten Teil4
2. Mandatory Access Control (MAC)
Anwendungen weisen Programmierfehler auf – damit müssen wir leben. Einige dieser Fehler sind allerdings so schwerwiegend, dass es einem Angreifer gelingt, ein fremdes System zu infiltrieren bzw. komplett zu übernehmen / auszuspionieren. Solche Schwachstellen werden in der Regel als »kritisch« bezeichnet. Klassischerweise bleibt den Benutzern und Administratoren nur übrig, ihr System ständig auf dem neuesten Stand zu halten – was allerdings nicht gegen Zero-Day-Exploits hilft. Gerade Schadprogramme gelangen häufig über Sicherheitslücken bzw. Zero-Days im Browser oder häufig verwendeten Bibliotheken auf ein System. Je nach Ausrichtung manipulieren sie dort dann Konfigurationsdateien, installieren Rootkits oder verfolgen andere böswillige Zwecke.
Aus dieser Misere können wir uns durch Sicherheitsframeworks wie AppArmor, SELinux (Achtung: Entwickelt von der NSA), SMACK oder Tomoyo befreien. Diese basieren auf dem MAC-Konzept – ein Zugriffskontrollmodell, um den Zugriff auf die unterschiedlichsten Ressourcen wie Prozesse oder Dateien zu steuern. Durch die Zugriffskontrolle wird sozusagen »gutartiges« Programmverhalten erzwungen und die negative Auswirkung, von bis dato unbekannten Schwachstellen, auf das System vermindert.
Unterstütze den Blog mit einem Dauerauftrag!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Zugriffskontrolle
Das Prinzip zur Überwachung und Steuerung von Zugriffen auf Ressourcen ist in der Informatik unter dem Begriff Zugriffskontrollmodell bekannt. Auf Basis von Regeln und Strukturen wird durch ein Zugriffskontrollmodell entschieden, ob bspw. der Zugriff auf einen Prozess, Datei oder Netzwerkdienst ermöglicht wird. Vereinfacht ausgedrückt regelt ein solches Modell: »Wer darf in einem IT-System auf welche Ressourcen wie zugreifen«. Abstrakt werden Zugriffskontrollmodelle anhand drei grundlegender Elemente beschrieben:
- Subjekt: Initiator der Handlung bzw. agierende Einheit
- Benutzer (bspw. Alice, Bob), Benutzergruppen
- (System-)Prozesse, Rechner
- Objekt: Gegenstand der Handlung bzw. zu schützende Einheit
- (System-)Prozesse, Dateien
- (Benutzer-)Konten
- Regel bzw. Zugriffsrecht: Zugriffsmethode, die einem Subjekt auf ein Objekt gewährt wird
- Lesen, schreiben, löschen, ausführen, etc.
Zur Kategorie der Zugriffskontrollmodelle zählt unter anderem das Mandatory Access Control-Konzept (MAC). Bei einem MAC wird auf Basis von Regeln entschieden, ob und in welcher Weise ein Subjekt (Benutzer, Prozess) auf ein Objekt (Datei, Prozess) zugreifen darf. Dieses Konzept soll im Idealfall den unautorisierten Zugriff auf Informationen systemtechnisch verhindern.
3. AppArmor
Seit dem Jahr 2006 ist AppArmor unter der GPL als Open Source freigegeben. Ursprünglich wurde es von Immunix entwickelt, das später von Novell aufgekauft wurde. Aktuell »kümmert« sich insbesondere Canonical (Ubuntu) um das Projekt.
AppArmor zählt zu den MAC basierten Sicherheitsframeworks für Linux. Wie auch SELinux und Tomoyo setzt AppArmor auf das LSM-Framework und arbeitet folglich als Kernelmodul, dass eine Schnittstelle für sicherheitsrelevante Aktionen bereitstellt. Das Linux Security Modules (LSM) Prinzip ist nicht unumstritten. Unter anderem kritisieren die Entwickler von RSBAC und auch grsecurity das LSM-Framework. Die Kritik ist nicht unberechtigt und dennoch muss an dieser Stelle auch Folgendes berücksichtigt werden:
- Sowohl RSBAC, als auch grsecurity haben es nie offiziell in den Kernel geschafft
- Insbesondere der Mehraufwand für die Installation (Kernel-Patching) und der Betrieb ist bei beiden Projekten nicht zu vernachlässigen
Ob jemand AppArmor auf Basis von LSM bevorzugt oder eher zu grsecurity greift ist neben einer Glaubensfrage auch immer eine Abwägung zwischen Aufwand und Nutzen. Nach meiner Auffassung bietet die Kernel-Modifikation grsecurity + PaX im Vergleich zu LSM insgesamt mehr Sicherheit – allerdings wird dieses »mehr« an Sicherheit teuer erkauft. Gerade die Installation und auch der Betrieb von grsecurity in Kombination mit PaX kann einem graue Haare verursachen – darauf werde ich in einem weiteren Artikel noch einmal gesondert eingehen.
3.1 Warum AppArmor?
Im letzten Beitrag hatte ich kurz das KISS-Prinzip (Keep it simple, stupid) angesprochen. IT-Sicherheitsmaßnahmen sind nur dann wirkungsvoll und empfehlenswert, wenn sie überschaubar bzw. kontrollierbar sind und ihr sowohl die Konfiguration, als auch Anwendung beherrscht. Insbesondere deshalb habe ich mich für AppArmor und gegen SELinux oder Tomoyo entschieden. Am Ende ist es dann aber auch wieder eine Glaubensfrage, welches Sicherheitsframework ihr einsetzt.
3.2 Installation
Bei den folgenden Linux-Distributionen ist AppArmor bereits fester Bestandteil der Standardinstallation und schützt über sogenannte Profile schon einige Standardanwendungen:
Falls AppArmor nicht fester Bestandteil der Standardinstallation sein sollte, gestaltet sich eine nachträgliche Installation bei vielen Distributionen -dank LSM-Kompatibilität- als denkbar einfach:
Andere Distributionen wie CentOS oder Fedora machen es dem Benutzer hingegen schwer AppArmor zu benutzen.
3.3 Profile
Irgendwo müssen Regeln definiert werden, mit denen AppArmor den Zugriff auf Ressourcen überwacht und steuert. Für diesen Zweck werden bei AppArmor Profile angelegt, die dann bspw. festlegen, ob eine Anwendung auf einem Netzwerkport lauschen darf oder auf andere Prozesse und Dateien Zugriff erhält. Je nach Betriebsmodus eines Profils wird bei einem Verstoß der Anwendung gegen die vordefinierten Regeln unterschiedlich reagiert:
- Complain: Das ist der Lernmodus, in dem eine Zugriffsverletzung mitgeloggt, allerdings nicht verhindert wird. Dieser Modus eignet sich für die Erstellung neuer Profile bzw. Regeln einer Anwendung.
- Audit: In diesem Modus werden Regelanwendungen, als auch Verstöße protokolliert. Dieser Modus eignet sich für die Fehlersuche, falls eine Anwendung aufgrund zu strikter Regeln abstürzt oder eine Fehlfunktion vorliegt.
- Enforce: Alle definierten Regeln eines Profils werden zwingend angewendet. Das bedeutet: Alle Verstöße bzw. Zugriffsverletzungen werden protokolliert und unterbunden. Dieser Modus ist ideal für den Dauerbetrieb.
Der Speicherort für Profile variiert je nach Linux-Distribution. Unter Ubuntu werden die Anwendungsprofile bspw. unter
/etc/apparmor.d/
abgelegt.
Ubuntu und openSUSE liefern in der Standardinstallation bereits etliche Profile mit, die (Standard-)Anwendungen bereits »schützen«. Daher behaupte ich: Viele Benutzer dieser Distributionen werden vermutlich gar nicht bemerkt haben, dass AppArmor bereits im Hintergrund werkelt. Mit jeder neuen Ubuntu-Version werden Profile von den Entwicklern und auch freiwilligen Supportern ergänzt – diese umfassen sowohl Anwendungen, als auch Dienste.
Im Ubuntu-Repository lassen sich Anwendungsprofile für die unterschiedlichen Versionen von jedem einsehen. Falls ihr später neue Profile erstellt oder bereits bestehende anpassen wollt, findet ihr dort Vorlagen bzw. Beispiele.
3.4 Wichtige Befehle
Nach der Installation von AppArmor stehen euch unterschiedliche Tools bereit. Falls für eine Anwendung noch kein Profil zur Verfügung steht, oder ihr selbst eines bauen möchtet, unterstützen euch dabei die folgenden Befehle:
- aa-autodep <Pfad zum Programm>: Erstellung eines Basis-Profils im Complain-Modus
- aa-genprof <Pfad zum Programm>: Erstellung eines Basis-Profils mit interaktiver Ergänzung von Regeln und abschließender Versetzung des Profils in den Enforce-Modus
Wichtig: Läuft eine Anwendung bereits, lässt sich das zugehörige AppArmor-Profil nicht nachträglich aktivieren. Nach der Profilerstellung oder Änderungen ist ein Neustart der Anwendung erforderlich.
Nach der Erstellung oder für bereits vorhandene Profile könnt ihr entscheiden, in welchem Modus ein Profil operieren soll:
- aa-complain <Pfad zum Profil>: Profil in den Complain-Modus versetzen
- aa-audit <Pfad zum Profil>: Profil in den Audit-Modus versetzen
- aa-enforce <Pfad zum Profil>: Profil in den Enforce-Modus versetzen
Falls eine Anwendung bzw. eine bestimmte Funkion nicht wie gewohnt funktioniert, kann ein nachträgliches Feintuning des Profils notwendig sein:
- aa-logprof <Pfad zum Profil>: Interaktive Ergänzung von Regeln anhand der Einträge in /Pfad/zu/syslog
Und zum Schluss noch zwei wichtige Befehle, um sich einen Überblick zu verschaffen:
- aa-status: Ausgabe einer Liste aller geladenen AppArmor-Profile mit Angabe des Modus
- aa-unconfined: Ausgabe der Prozesse mit Netzwerkzugriff ohne Profil
3.5 Betrieb: Wo fange ich an?
Sowohl Ubuntu, als auch openSUSE Anwender können auf eine Vielzahl von AppArmor-Profilen zurückgreifen. Doch unabhängig von den mitgelieferten Profilen ist es ratsam, dass ihr euch intensiv mit AppArmor befasst, zumal nicht für jede Anwendung ein Profil mitgeliefert wird. Insbesondere die Anwender weiterer Distributionen werden sich zwangsläufig mit der Erstellung und Feinjustierung von Profilen beschäftigen müssen – denn die von den jeweiligen Distributionen »gepflegten« Profile sind oftmals veraltet oder unvollständig.
An dieser Stelle werde ich das Rad nicht neu erfinden, sondern auf diverse Beiträge verlinken, die aus meiner Sicht für die Handhabung und den Betrieb von AppArmor essentiell sind. Es ist wie so oft: Für ein Quäntchen mehr Sicherheit müsst ihr euch zunächst einarbeiten und bereit sein, die Bequemlichkeit hintenan zu stellen:
- Allgemeine Beschreibung von AppArmor
- Anleitung zur Erstellung neuer Profile
- AppArmor Profil-Vorlagen (von Ubuntu)
Hinweis: Nach meiner Auffassung sind einige der mitgelieferten Profile zu grobgranular – sind also wenig restriktiv und erlauben Anwendungen weitreichende Zugriffe auf unterschiedliche Ressourcen. Das macht die Profile nicht per se unsicher, allerdings favorisiere ich persönlich immer die Erstellung eines individuellen Anwendungsprofils, dass euren Anforderungen gerecht wird.
3.6 Welche Anwendungen sollten beobachtet werden?
Ein Rundumschutz aller Anwendungen und Dienste ist kaum realistisch, da der Aufwand der Profilerstellung hierbei berücksichtigt werden sollte. Generell empfehlenswert ist die Überwachung all jener Programme, die direkten Zugriff auf das Internet haben. Dazu zählen bspw. der Browser, E-Mail Client, Chat-Programm, usw. Sekundär sollten all jene Anwendungen im Fokus stehen, die Dateien darstellen, öffnen oder in irgendeiner Form bearbeiten. Also PDF-Reader oder Video-und Musikplayer. Grob kann man auch sagen: Standardanwendungen – diese stehen bei Angreifern aufgrund ihrer hohen Verbreitung meist hoch im Kurs.
Persönlich übernehme ich eine Vielzahl der Ubuntu-Profile. Für Anwendungen, die direkten Zugriff auf das Internet haben, erstelle ich in der Regel eigene, restriktive Profile.
4. Profile: Tor Browser Bundle
Die Linux-Distributionen Whonix und Tails – beide auf Sicherheit und Privatsphäre bedacht – setzen ebenfalls AppArmor ein. Unter anderem wird damit das Tor Browser Bundle mit einem entsprechenden Profil »isoliert« bzw. im Zaun gehalten. Persönlich halte ich sowohl das Profil für Whonix, als auch das Profil für Tails als zu grobgranular – aus Sicht der »User-Experience« bzw. dem Komfort sind die Regeln allerdings absolut nachvollziehbar.
Wer wenig Wert auf Bequemlichkeit legt, die Audioausgabe nicht benötigt und nur das Notwendigste erlauben möchte, der kann gerne einen Blick auf mein Tor Browser Bundle Profil werfen:
Profil TorBrowser Launcher:
# Last Modified: Fri Feb 19 12:28:11 2016
#include <tunables/global>
@{LAUNCHER} = /path/to/tor-browser-bundle
/path/to/tor-browser-bundle/tor-browser*/Browser/start-tor-browser {
#include <abstractions/base>
## ACCESS
/bin/bash rix,
/usr/bin/dirname rix,
/usr/bin/getconf rix,
## TOR LAUNCHER
owner @{LAUNCHER}/tor-browser*/Browser/firefox px,
owner @{LAUNCHER}/tor-browser*/Browser/start-tor-browser r,
}
Profil TorBrowser Firefox:
# Last Modified: Fri Feb 19 12:29:40 2016
#include <tunables/global>
@{TBB} = /path/to/tor-browser-bundle
/path/to/tor-browser-bundle/tor-browser*/Browser/firefox {
#include <abstractions/base>
## ACCESS
## Access themes (GUI)
/usr/share/themes/** r,
## FIREFOX (TOR)
owner @{TBB}/tor-browser*/Browser/* r,
owner @{TBB}/tor-browser*/Browser/*/ r,
owner @{TBB}/tor-browser*/Browser/*.so mr,
owner @{TBB}/tor-browser*/Browser/.cache/ w,
owner @{TBB}/tor-browser*/Browser/.cache/* rwk,
owner @{TBB}/tor-browser*/Browser/.cache/fontconfig/ w,
owner @{TBB}/tor-browser*/Browser/.cache/fontconfig/* rwl,
owner @{TBB}/tor-browser*/Browser/browser/** r,
owner @{TBB}/tor-browser*/Browser/browser/components/*.so mr,
owner @{TBB}/tor-browser*/Browser/defaults/pref/ r,
owner @{TBB}/tor-browser*/Browser/defaults/pref/* r,
owner @{TBB}/tor-browser*/Browser/components/*.so mr,
owner @{TBB}/tor-browser*/Browser/components/components.manifest r,
owner @{TBB}/tor-browser*/Browser/{Desktop,Downloads}/ rw,
owner @{TBB}/tor-browser*/Browser/{Desktop,Downloads}/** rwk,
owner @{TBB}/tor-browser*/Browser/fonts/* r,
owner @{TBB}/tor-browser*/Browser/icons/* r,
owner @{TBB}/tor-browser*/Browser/TorBrowser/Data/fontconfig/* r,
owner @{TBB}/tor-browser*/Browser/TorBrowser/Data/Browser/profiles.ini r,
owner @{TBB}/tor-browser*/Browser/TorBrowser/Data/Browser/profile.default/ r,
owner @{TBB}/tor-browser*/Browser/TorBrowser/Data/Browser/profile.default/** rwk,
owner @{TBB}/tor-browser*/Browser/TorBrowser/Tor/*.so.* mr,
owner @{TBB}/tor-browser*/Browser/TorBrowser/Tor/tor px,
}
Zugegeben – das Profil ist sehr restriktiv und folgende Aktionen lassen sich damit nicht durchführen:
- Download von Dateien
- Wiedergabe von Audio
- Update des Bundles (es ist immer ein Download einer neuen Version notwendig)
- […]
Das Profil ist also allein zum Surfen bzw. konsumieren von Text ausgelegt. Wer möchte kann es gerne anpassen und erweitern. Für das Profil gebe ich übrigens keinen Support – das war in erster Linie als Beispiel gedacht. Wer indes noch »Einsparungspotenzial« findet, der kann mir gerne einen Hinweis hinterlassen.
5. Fazit
Im Vergleich zu anderen Sicherheitsframeworks zur Überwachung und Steuerung von Ressourcen halte ich AppArmor für vergleichsweise anwenderfreundlich. Wer sich die Zeit nimmt, um sich in AppArmor einzuarbeiten, neue Profile erstellt und bestehende anpasst, der wird eine konstante Lernkurve haben. Am Ende kann sich der ganze Aufwand bezahlt machen – ihr seid dann besser vor den Folgen eines Zero-Day-Exploits geschützt.
AppArmor und Co. konzentrieren sich hauptsächlich auf Anwendungen. Der Linux-Kernel wurde in der bisherigen Artikelserie noch nicht berücksichtigt. Im letzten Beitrag soll sich das ändern: Wer das Optimum an Sicherheit für seinen Desktop-Rechner herausholen möchte, der kommt an grsecurity kaum vorbei. Eine Warnung schicke ich allerdings gleich voraus: Das ist nur etwas für echte Linux-Kenner. Alle anderen sollten sich mit AppArmor oder einem vergleichbaren Sicherheitsframework anfreunden.
Bildquellen:
Helmet: Zlatko Najdenovski from www.flaticon.com is licensed by CC 3.0 BY
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Firejail – Linux härten Teil4
Konfiguration des Tor-Browser-Bundles – Not my data! Teil3
AFWall+: Wie ich persönlich die Android-Firewall nutze
Android: Apps über Orbot routen
Sicheres Desktop System – Linux härten Teil1
18 Ergänzungen zu “AppArmor – Linux härten Teil3”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Als nicht so tiefer Kenner ist mir die Abgrenzung AppArmor zu FireJail nicht so ganz klar.
Ergänzung? Oder Alternative?
Tipps, wann man welches verwenden soll, wäre für Security-Interessierte, aber nicht Security-Experte ganz hilfreich.
Firejail eigent sich um eine Anwendung »mal schnell« in ein Gefängnis bzw. Sandbox zu stopfen. Für den Dauerbetrieb eignet sich AppArmor nach meiner Auffassung eher. Firejail basiert im Gegensatz zu AppArmor nicht auf LSM, sondern verwendet eine eigene User-ID für die Sandbox und nutzt die Namespaces des Linux-Kernels, sowie seccomp-bpf.
Hallo Mike!
Danke für den tollen Artikel. Bin gerade dabei das ganze umzusetzen.
Ich nehme an, dass beim einsatz von RSBAC oder grsecurity Apparmor nicht mehr nötig ist. Stimmt meine Annahme?
Die stabilen Kernel Patches von grsecurity sind ja nun leider nur mehr für Kunden verfügbar. Sind diese auch für Privatpersonen erhältlich und falls ja zu welchem Preis?
Falls nein, wie sieht die Stabilität des 4.7er Kernels mit den grsecurity testing patches aus?
Vom Produktiveinsatz beim testing branch wird von den Entwicklern ja abgeraten.
Könntest du vielleicht einen kurzen Vergleich von RSBAC und grsecurity ziehen? Im Sinne von Stabilität, Useability/Wartungsaufwand und Sicherheit.
Das kann man so sehen – ja. Grsecurity hat ein Role-Based Access Control (RBAC) System integriert.
Ein Teil der restlichen Fragen werden mit dem kommenden Beitrag der Serie beantwortet. Thema dieses Beitrags: AppArmor. ;-)
AppArmor ist von der NSA entwickelt…warum empfiehlst du das?
Entweder das ist ein Troll-Versuch oder du hast den Text nicht gelesen. Beides disqualifiziert dich eigentlich für einen Kommentar.
Bevor hier eine Legende entsteht: AppArmor wurde NICHT von der NSA entwickelt.
Du verwechselst AppArmor mit SELinux.
Hallo Mike!
Danke für den guten Artikel! Einige Anmerkungen dazu:
1. Die Installation von AppArmor in Arch Linux ist leider nicht so einfach, wie du schreibst. Im Arch Kernel wurde vor, glaube ich, ca. 2 Jahren die Unterstützung für AppArmor, SELinux, Tomoyo entfernt. Wer AppArmor dennoch nutzen will, muss sich daher seinen eigenen Kernel kompilieren (https://wiki.archlinux.org/index.php/AppArmor). Was nicht weiter schwierig ist, aber man muss es eben wissen.
2. Du schreibst in einem Kommentar, dass AppArmor bei einem grsecurity System nicht notwendig ist, weil es RBAC anbietet. Interessant ist allerdings, dass Subgraph OS trotz grsecurity auf AppArmor setzt. Dafür muss es ja Gründe geben …
3. Du schreibst: „Firejail eigent sich um eine Anwendung »mal schnell« in ein Gefängnis bzw. Sandbox zu stopfen. Für den Dauerbetrieb eignet sich AppArmor nach meiner Auffassung eher.“ Das sehe ich anders: Zu einen arbeitet Firejail mit Technologien, die AppArmor nicht anbietet, z.B. das von dir erwähnte seccomp-bpf. Damit werden Systemaufrufe gefiltert, wodurch die Angriffsfläche des Kernels dramatisch verkleinert wird und es deutlich schwieriger wird, eventuell vorhandene Sicherheitslücken im Kernel auszunutzen. Zum anderen wird auch in den Firejail-Profilen über die Einbindung der *.inc Dateien in /etc/firejail der Zugriff auf fast alle systemkritischen Verzeichnisse/Dateien unterbunden, auch auf solche im home. Und über gezieltes whitelisting lässt sich der Zugriff von, z.B., Firefox auf die Dateien in home drastisch auf ~/.mozilla und ~/Downloads einschränken. Insofern ist durchaus eine Flexibilität vorhanden, auch wenn sie „grobgranularer“ als unter AppArmor bleibt. Im Übrigen lassen sich nicht nur Anwendungen firejailen, sondern alle möglichen Dienste. Ich habe jedenfalls schon seit längerem nicht nur Anwendungen wie Firefox, Thunderbird, LibreOffice, VLC, Okular oder Gwenview unter Firejail laufen, sondern auch z.B. dnsmasq und dnscrypt-proxy. Und über das mitgelieferte Tool firecfg bzw. manuelle symlink invocation (https://l3net.wordpress.com/2016/02/04/firejail-0-9-38-release-announcement/) ist die Anwendung auch sehr bequem.
Insgesamt würde ich sagen: Mit Firejail lässt sich eine System sehr wohl gut härten. Es ist in der Anwendung deutlich einfacher als AppArmor, aber weniger „feinkörnig“. Dafür arbeitet es mit anderen Technologien, die in den letzten Jahren Einzug im Kernel erhalten haben. Insofern spricht m.E. nichts dagegen, beides einzusetzen, da dadurch eine zusätzliche Sicherheitsschicht eingezogen wird.
Hallo seeker. Danke für den tollen Kommentar.
1. Das stimmt. Einfach im Sinne von: Arch-Linux Benutzer sollte dies vor keine größere Herausforderung stellen. ;-)
2. Ich vermute Subgraph OS greift in erster Linie auf die Kernel-Patches von grsecurity zurück. Das Schöne ist ja: AppArmor und grsecurity schließen sich nicht aus, sondern können gleichzeitig verwendet werden. Und ich vermute auch: Die Entwickler greifen deshalb auf AppArmor zurück, weil das in grsecurity integrierte RBAC sehr mächtig, aber auch sehr komplex ist.
3. Eben das feingranulare fehlt mir bei Firejail. Und ob es tatsächlich einfacher ist als AppArmor? Insgesamt fehlt mir bei Firejail noch etwas die Langzeiterfahrung. Ich beobachte die Entwicklung, kann aber noch nicht wirklich einschätzen, wie solide das Ganze ist. Sagen wir so: Mir fehlt noch das »Vertrauen«.
Wenn du aber mal einen Beitrag zu Firejail schreiben möchtest, dann melde dich bei mir.
Mal wieder ein sehr interessanter Text :)
Vielen dank, mit sowas hatte ich mich noch nicht beschäftigt!
LG
Sorry, Mike hab es verwechselt. Meinte SELinux. Ist sogar auf deren Website…
Nur eine kleine Randbemerkung zur Anrüchigkeit von SELinux, dieser NSA-Ausgeburt. Ja, es stimmt, wenigstens insofern, dass dieses Linuxkernel-Sicherheitsmodul auf einigen Vorgängerprojekten basiert, die von der NSA betrieben wurden.
Und?
Wir reden hier über quelloffene Software, über ein Projekt, dessen Entwicklung transparent betrieben wird und das sicher unter genauerer Beobachtung steht als die anderer Kernelmodule. Das reicht für meine Sicherheitsbedürfnisse völlig. (Für die Abwägung der Vor- und Nachteile von SELinux, AppArmor und grsecurity fehlt es mir allerdings an der nötigen Kompetenz.)
UND: Wenn NSA-Wurzeln bei SELinux als K.O.-Kriterium gelten, dann kann ich auch Tor nicht mehr einsetzen, denn dieses Projekt ist ursprünglich von der U.S. Navy initiiert worden … und am besten nutze ich auch das Internet nicht mehr, denn das hat ja auch militärische US-amerikanische Geburtshelfer gehabt.
Naja sagen wir mal so: SELinux wurde primär von der NSA (ca Anfang 2000) entwickelt. Das alleine verursacht bei mir schon ein mulmiges Gefühl.
Denk einfach mal kurz an die Verschlüsselungsalgorithmen die von der NSA vorgeschlagen wurden. Anfangs wurden von den Wissenschaftlern keine Schwächen gefunden, heute wissen wir, dass die Algorithmen Schwächen aufweisen, die die NSA wahrscheinlich schon damals kannte.
Quelloffenheit ist leider auch keine Garantie für „Backdoorfreiheit“. Quelloffenheit macht es lediglich deutlich einfacher Backdoors zu finden, garantiert jedoch trotzdem nicht dass sie gefunden werden.
Bei dem Umfang des SELinux Projekts kann eine geschickt getarnte Backdoor vielleicht nicht gefunden werden.
Der wichtigste Punkt jedoch ist: es gibt mindestens gleichwertige Alternativen. Somit besteht kein Grund auf die NSA-(Miss)geburt zu setzen.
Oder anders: wenn die NSA eine Linux-Distro rausbringen würde, würdest du sie trotz hunderter Alternativen verwenden?
Bei Tor siehts in punkto Alternativen je nach Einsatzgebiet anders aus:
– für anonymes Surfen im normalen Netz ist Tor leider alternativlos, da JonDo kaum noch gepflegt wird – andernfalls wäre JonDo Premium vielleicht Tor vorzuziehen. Man könnte zwar auch I2P und Freenet für das Surfen im normalen Netz verwenden, das Ganze ist für diesen Einsatzzweck jedoch nicht optimal
– für die jenigen die Tor als Darknet verwenden (die Gründe seien jetzt mal dahingestellt – gehen wir mal von anonymen Filesharing im Falle eines Journalisten etc aus), würde ich ganz klar I2P oder Freenet gegenüber Tor vorziehen.
Da Tor das populärste und am einfachsten zu verwendende Darknet ist, wird es ständig von NSA und co attackiert.
Auch Sicherheitsforscher und Ex-Tor Entwickler sind leider bestechlich, somit wurde 2014 der Blackhat Talk zu Deanonymisierung der Tor User abgesagt, da die Sicherheitsforscher bereits vom FBI für den Tor-Exploit entlohnt wurden.
Naja das Internet ist ein ganz anderes Thema. Die Protokolle IP und TCP wurde nicht gerade mit „Privacy in mind“ designt. Hier spielen leider immer politische Entscheidungen im Falle der Standardisierung eine Rolle und die sind, wie in der Politik üblich nicht immer zum Wohle der Bevölkerung.
Ich fürchte, die Sache ist so einfach nicht. Unter ethischen Gesichtspunkten steht unter allen Linux-Distros Debian wegen seiner nicht kommerziell ausgerichteten Entwickler-Community mit ihren sauberen Grundsätzen wohl an erster Stelle. Andererseits reden wir hier über eine Distro, die 23 Monate lang ein OpenSSL-Paket mit einer verheerenden Sicherheitslücke im Zufallszahlengenerator an alle Welt verteilt hat.
Andererseits gibt es mit Fedora eine Distro, die massgeblich von einem Konzern (böse!) gesponsort wird, der außerdem enge Geschäftsbeziehungen zum US-Militär (böse-böse!) und auch der NSA (böse-böse-böse!) unterhält – sowohl bei der NSA als auch beim US-Militär ist Red Hat Enterprise Linux die bevorzugte Linux-Distro.
Ginge ich nach Sympathie, würde auf meinen Rechnern sicher Debian laufen (wofür es auch sonst gute Argumente gibt), statt dessen habe ich Fedora im Einsatz (wofür es technisch gesehen auch gute Argumente gibt).
Dass Quelloffenheit eine notwendige, aber nicht hinreichende Voraussetzung für Sicherheit ist, steht dabei außer Frage. Aber die Annahme, dass eine Staatsbeteiligung ein sicheres Indiz dafür ist, dass etwas faul ist, scheint mir doch naiv. Das fängt schon beispielsweise mit den 319.000 Mark an, mit denen das Bundeswirtschaftsministerium die Arbeit von Werner Koch an GnuPG gefördert hat. Hat damit GnuPG seine Vertrauenswürdigkeit verloren?
Es gibt nicht DEN Staat, zumindest nicht in den Nicht-Diktaturen, in denen wir leben. Zu genau der Zeit, als das Wirtschaftsministerium GnuPG gefördert hat, war der notorische Überwachungsjunkie Otto Schily Bundesinnenminister. Und während heute in den USA staatlicherseits das Recht auf Privatsphäre demontiert wird, gibt es gleichzeitig amerikanische Steuergelder für Projekte wie Tor, The Guardian Project, Qubes oder NoScript.
Wer heute Vertrauen fordert für etwas, weil es staatlichen Ursprungs ist, ist ein Idiot. Aber wer einfach dieser Unschuldvermutung eine Schuldsvermutung entgegensetzt ist, ist naiv.
Und um noch mal zu meiner Betriebssystem-Wahl zurückzukommen: Als ich zwischen Debian und Fedora schwankte und mich letztendlich für letzteres entschied, dann habe ich es nicht getan, weil ich Fedora für sicherer hielt. (Mal abgesehen von meiner mangelnden Kompetenz wüßte ich niemand auf diesem Planeten, der angesichts von zwei Mount Everests an Code zu einer fundierten Abwägung in der Lage wäre.) Aber die gewisse Staatsnähe von Red Hat verunsichert mich zumindest nicht – weil ich nicht davon ausgehe, dass sich das Militär für ein mit Backdoors gespicktes OS entscheiden würde.
Ja die legendäre Debian Lücke im SSL Package war ein herber Schlag für die Community, nur die Offenheit gegenüber Sicherheitslücken finde ich nichtsdestotrotz erstrebenswert. Die Lücken werden bei Debian in der Regel am gleichen Tag noch behoben.
Natürlich wird RHEL von den Unternehmen gesponsert.
Du hast schon recht, man kann aus der Tatsache das staatliche Sponsoren beteiligt sind dem Projekt nicht automatisch böse Absichten unterstellen.
Jedoch führt NSA-Mitarbeit an einem Projekt im Gegensatz zu Sponsoring bei mir trotzdem zu einem schlechten Bauchgefühl.
Vor der Snowden-Ära hätte ich villeicht noch geglaubt: „das würde die NSA doch niemals tun“.
Backdoors im Thinkpad UEFI, Backdoors in den Juniper Firewalls …
Wirklich vertrauen kkönnen wir leider keine Hardware oder Software.
Bezüglich Betriebssystemwahl:
Ich habe mehrmals zwischen Fedora, openSuSe und Debian hin- und hergewechselt und bin aus den von dir genannten Gründen bei Debian geblieben.
Natürlich stehen hinter Fedora und openSuSe die Firmen, jedoch ist der Entwicklungsprozess bei den beiden Distros sehr transparent.
Wer Debian, Fedora, openSuSe, Parabola/Arch oder Gentoo einsetzt ist vermutlich auf der sicheren Seite. Bei Canonical hätte ich nicht so ein gutes Gefühl
Ich würde vorschlagen wir bleiben beim Thema: Linux-Hardening mit AppArmor.
Hallo!
Soweit ich das verstehe, arbeiten Greg-KH und Kees Cook daran die besten patches aus dem grsecurity/pax Projekt in den Mainline Kernel zu überführen…
Aus dem Interview zu entnehmen:
https://www.linux.com/news/greg-kh-update-linux-kernel-46-next-week-new-security-features
In Mikes Beitrag geht’s um das Härten von Desktop-Systemen. Trotzdem hier mal ein kleiner Schlenker zu Android, bei Ars Technica ist da ein bemerkenswerter Beitrag zum Copperhead-Projekt erschienden:
https://arstechnica.com/information-technology/2016/08/copperhead-os-fix-android-security/