Sichern Sie Linux mit AppArmor

Der vorherige Artikel befasste sich mit SELinux. Mein Eindruck von diesem Sicherheitssystem ist zweifach. Einerseits gibt es in der IT nie zu viel Sicherheit, und SELinux enthält alles, was Sie zum Schutz des Betriebssystems und der Anwendungen vor unbefugtem Zugriff benötigen. Andererseits sieht es zu umständlich und unnötig komplex aus, was seine Verwendung unpraktisch macht. Mehr als ein- oder zweimal in den Benutzerhandbüchern zur Installation kommerzieller Software habe ich Empfehlungen zur Ausführung von setenforce 0 gesehen, bevor mit der Installation begonnen wird.



Eine Lösung, die die Hälfte der Funktionalität von SELinux bietet, jedoch viel einfacher zu konfigurieren und zu betreiben ist, kann einen zuverlässigeren Schutz bieten, schon allein deshalb, weil es nicht beängstigend ist, sich mit all diesen Domänen, Richtlinien und Rollen zu befassen. Genau das bietet AppArmor.



AppArmor ist wie SELinux eine MAC-Implementierung (Mandatory Access Control), die auf der LSM-Architektur (Linux Security Modules) basiert. Beim Sicherheitsmodell von Apparmor geht es darum, Zugriffssteuerungsattribute nicht an Benutzer, sondern an Programme zu binden. AppArmor bietet Isolation durch Profile, die normalerweise beim Booten in den Kernel geladen werden.



AppArmor unterscheidet sich von anderen Linux-MAC-Implementierungen dadurch, dass es pfadbasiert ist und Sie auch Durchsetzungs- und Warnprofile mischen können. Darüber hinaus verwendet AppArmor Dateianhänge, um die Entwicklung zu erleichtern, und weist eine viel geringere Eintrittsbarriere auf als SELinux.

DAC und MAC

Die DAC-Architektur (Discretionary Access Control) beschränkt den Zugriff auf kritische Ressourcen basierend auf den Attributen der Subjekte oder der Gruppe, zu der sie gehören. Diese Attribute bestimmen die Zugriffsrechte auf die Ressourcen des Dateisystems. Jeder Administrator ist sich der Bedeutung von Berechtigungen zum Lesen (Lesen), Aufzeichnen (Schreiben) und Ausführen (eXecute) bewusst.

Diese Attribute gelten für drei Benutzerkategorien: Benutzer (Eigentümer), Gruppe (Gruppe), andere (andere). Die Besitzerkategorie bezieht sich auf einen einzelnen Betriebssystembenutzer, während eine Gruppe viele Betriebssystembenutzer enthalten kann. Die Restkategorie umfasst diejenigen Benutzer, die nicht zu den ersten beiden gehören.

Das DAC-Modell gibt dem Ressourcenbesitzer das Recht, die Art des Zugriffs für die angegebenen Benutzerkategorien zu bestimmen. Diese Differenzierung des Zugriffs eignet sich zum Schutz vor unbeabsichtigten Benutzeraktionen und ermöglicht die Beantwortung folgender Fragen:

• Welche FS-Ressourcen stehen einem bestimmten Betriebssystembenutzer zum Lesen, Schreiben und Ausführen zur Verfügung?
• Welche FS-Ressourcen stehen dieser Gruppe zum Lesen, Schreiben und Ausführen zur Verfügung?
• Welche FS-Ressourcen stehen anderen Benutzern zum Lesen, Schreiben und Ausführen zur Verfügung?
• Welcher Benutzer verfügt über ausreichende Rechte, um diesen Prozess auszuführen?

Zahl: 1 DAC- und MAC-Sicherheitssysteme.



Das MAC-Sicherheitssystem (Mandatory Access Control) übernimmt eine zentralisierte Kontrolle über Zugriffsrichtlinienregeln, bei denen normale Benutzer keine Möglichkeit haben, Änderungen daran vorzunehmen. Der Richtlinien-Designer bestimmt, welche Programme oder Prozesse bestimmte Aktionen für Systemressourcen ausführen können. MAC konzentriert sich mehr auf Programme als auf Benutzer und löst das Problem der Abgrenzung des Prozesszugriffs auf Betriebssystemressourcen.

Im Wesentlichen versucht das MAC-Design, die Abgrenzung der Zugriffsrechte auf die Dokumentation in der physischen Welt zu replizieren. Wenn ein bestimmter Mitarbeiter das Recht hat, als "streng geheim" gekennzeichnete Dokumente zu lesen, hat er auch Zugriff auf vertrauliche und interne Standarddokumente. Das Gegenteil ist jedoch nicht der Fall. Gleiches gilt für die Zugriffsrechte von Betriebssystemprozessen in der MAC-Architektur. Wenn ein Programm also die Datei / etc / sudoers lesen kann, hat es auch Zugriff auf / etc / hosts, aber das Gegenteil ist auch nicht der Fall.

AppArmor installieren und konfigurieren

Die Grundelemente von AppArmor sind in Ubuntu Server vorinstalliert, da die Verwaltungstools und die Anwendungsprofile separat installiert werden müssen.

[admin@server ~]$ sudo aptitude install apparmor-utils apparmor-profiles
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Überprüfen Sie den Status vor dem Einstellen.

[admin@server ~]$ sudo apparmor_status
apparmor module is loaded.
31 profiles are loaded.
31 profiles are in enforce mode.
 /snap/snapd/10492/usr/lib/snapd/snap-confine
 /snap/snapd/10492/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 /usr/bin/man
 /usr/lib/NetworkManager/nm-dhcp-client.action
 /usr/lib/NetworkManager/nm-dhcp-helper
 /usr/lib/connman/scripts/dhclient-script
 /usr/lib/snapd/snap-confine
 /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 /usr/sbin/tcpdump
   ...
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Die letzten Zeilen geben die Durchsetzungs- und Beschwerdemodi an. Was sind diese Regime kurz gesagt?

• Im Enforce- Modus erzwingt der Kernel die in die Profildatei geschriebenen Regeln. Verstöße sind nicht zulässig und der entsprechende Eintrag geht in die Protokolle.
• Im Beschwerdemodus registriert AppArmor nur Verstöße, ohne die Aktionen selbst zu blockieren.

Der Inhalt des Apparmor-Profile-Pakets befindet sich im Ordner /usr/share/apparmor/extra-profiles/



, dort befinden sich mehr als hundert vorgefertigte Profile.

[admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |head
total 484
-rw-r--r-- 1 root system 1724 May 19 2020 README
drwxr-xr-x 3 root system 4096 Dec 8 10:14 abstractions/
-rw-r--r-- 1 root system 1319 May 19 2020 bin.netstat
-rw-r--r-- 1 root system 1815 May 19 2020 etc.cron.daily.logrotate
-rw-r--r-- 1 root system  948 May 19 2020 etc.cron.daily.slocate.cron
-rw-r--r-- 1 root system  722 May 19 2020 etc.cron.daily.tmpwatch
-rw-r--r-- 1 root system 2623 May 19 2020 sbin.dhclient
[admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |wc -l
118
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Bevor das Profil aktiv wird, müssen Sie es aus dem Ordner /usr/share/apparmor/extra-profiles/



in übertragen /etc/apparmor.d/



. Jetzt kann es studiert und auf Wunsch geändert werden. Nehmen wir zum Beispiel etwas Einfacheres /etc/apparmor.d/bin.ping



.

...
#include <tunables/global>
profile ping /{usr/,}bin/{,iputils-}ping flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability net_raw,
  capability setuid,
  network inet raw,
  network inet6 raw,

  /{,usr/}bin/{,iputils-}ping mixr,
  /etc/modules.conf r,

  # Site-specific additions and overrides. See local/README for details.
  #include <local/bin.ping>
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Bis auf die Mixr-Flags ist alles ziemlich klar. Beschreibung der Flaggenbedeutungen unten:

• r - lesen;
• w - aufnehmen
• a - inkrementelles Schreiben bis zum Ende der Datei aus dem englischen Anhang;
• k - Dateien sperren;
• l - symbolische Links zu ausführbaren Dateien erstellen;
• m - Laden ausführbarer Dateien in den Speicher;
• cx - Übergang zum Profil der unteren Ebene während der Ausführung;
• Cx - Übergang zu einem untergeordneten Profil bei Ausführung mit Clearing-Umgebungsvariablen;
• ix - Ausführungsvererbung;
• px - erfordert die Definition eines diskreten Sicherheitsprofils für die Ressource;
• Px - Die Definition eines diskreten Sicherheitsprofils für die Ressource ist erforderlich. Die Umgebungsvariablen werden gelöscht.
• ux - Überprüfen Sie nicht den Start neuer Prozesse.
• Ux - Überprüfen Sie nicht den Start neuer Prozesse und bereinigen Sie keine Umgebungsvariablen.

Sie können auch Capabilities



die Linux-Kernel angeben, die der Prozess verwenden darf. Ihre vollständige Liste finden Sie auf der entsprechenden Seite des Handbuchs.

Um vom Lernmodus in den erzwungenen Modus zu wechseln, müssen Sie den Befehl ausführen aa-enforce <prog_name>, - aa-complain <prog_name>



. Wenn Ping nach dem Aktivieren des erzwungenen Modus versucht, etwas zu tun, wird es von etwas, das von AppArmor nicht beabsichtigt wurde, blockiert.

[admin@server ~]$ sudo aa-enforce ping
Setting /usr/bin/ping to enforce mode.
[admin@server ~]$ sudo cp /usr/bin/man /usr/bin/ping
[admin@server ~]$ /usr/bin/ping ping
/usr/bin/ping: can't open the manpath configuration file /etc/manpath.config
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Wenn Sie ein neues Profil erstellen müssen, ist dies nicht schwierig. Zuerst müssen Sie mit dem Befehl eine Vorlage erstellen aa-autodep



und diese dann durch Ausführen füllen aa-genprof



. Ein Beispiel für einen interaktiven Dialog aa-genprof kostenlos unter dem Link .

Gebrauchte Materialien

• LINUX SECURITY PRIMER: SELINUX UND SMACK FRAMEWORKS
• AppArmor
• AppArmor, russischsprachige Dokumentation