SELinux auf Debian

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

SELinux statt AppArmor auf Debian

Diese Seite dokumentiert die Migration von AppArmor zu SELinux auf it2XX und die anschließende Evaluierung für sshd, Apache2 und nginx.

Hintergrund

Im Rahmen der Kursvorbereitung wurde AppArmor auf Basis eines Praxistests mit dem sshd-Profil aus apparmor-profiles-extra evaluiert. Dabei zeigten sich mehrere strukturelle Schwächen:

  • Das mitgelieferte sshd-Profil ist laut Debian-Paketbeschreibung explizit als experimentell gekennzeichnet und nicht für den enforce-Mode vorgesehen
  • Nach dem OpenSSH-Split (Version 9.8, sshd-session als separater Prozess) war das Profil nicht mehr aktuell und musste manuell über mehrere aa-logprof-Durchläufe nachgezogen werden
  • aa-logprof kann journald nicht nativ lesen; ohne zusätzlich installiertes rsyslog schlägt die Log-Auswertung fehl
  • Die generierten Vorschläge waren teils unpassend (z. B. Vorschlag von abstractions/apache2-common für einen SSH-Prozess)

Daraus folgt die Entscheidung, AppArmor zu entfernen und SELinux als MAC-System auf Debian einzusetzen und für sshd, Apache2 und optional nginx zu evaluieren.

AppArmor entfernen

Dienst stoppen und deaktivieren
  • systemctl stop apparmor
  • systemctl disable apparmor
Pakete entfernen
  • apt purge apparmor apparmor-utils apparmor-profiles apparmor-profiles-extra python3-apparmor python3-libapparmor
  • apt autoremove
AppArmor im Kernel deaktivieren

Bootparameter prüfen:

  • cat /proc/cmdline | grep -i apparmor

Falls kein expliziter Parameter gesetzt ist, in /etc/default/grub ergänzen: 

GRUB_CMDLINE_LINUX_DEFAULT="... apparmor=0"
GRUB-Konfiguration neu erstellen und neu starten
  • update-grub
  • reboot

SELinux installieren

Pakete installieren
  • apt install selinux-basics selinux-policy-default auditd
SELinux aktivieren
  • selinux-activate
  • reboot

Beim ersten Boot nach der Aktivierung wird das komplette Dateisystem relabelt. Dieser Vorgang kann je nach Systemgröße mehrere Minuten dauern.

Zunächst im permissive Mode testen
  • setenforce 0
  • getenforce

Erst nach erfolgreicher Prüfung aller Dienste auf enforcing umstellen, in /etc/selinux/config: 

SELINUX=enforcing

Evaluierung: sshd

Das ssh-Policy-Modul wird von der Standard-Policy automatisch anhand des installierten Pakets geladen.

Paket sicherstellen
  • apt install openssh-server
Kontext prüfen
  • ps -eZ | grep sshd
  • ls -Z /usr/sbin/sshd

Erwarteter Typ: sshd_t für den Prozess, sshd_exec_t für die Binary.

Denials nach Testlogin auswerten
  • ausearch -m avc -c sshd

Port ändern (Beispiel: 2222)

Modus prüfen
  • getenforce
Port in der Konfiguration setzen
  • cat /etc/ssh/sshd_config
Port 2222
...
Neustart (schlägt ohne Port-Label fehl)
  • systemctl restart ssh
Denial prüfen
  • ausearch -m avc -ts recent
Aktuell zugelassene Ports prüfen
  • semanage port -l | grep ssh_port_t
Port-Label ergänzen
  • semanage port -a -t ssh_port_t -p tcp 2222
Neustart erneut
  • systemctl restart ssh
Login-Test auf dem neuen Port
  • ssh -p 2222 user@it2XX

Hinweis: Bei semanage-Operationen erscheint häufig die Meldung libsemanage.add_user: user sddm not in password file. Das ist ein bekanntes, kosmetisches Problem der Debian-Paketierung der Default-Policy (sddm-User existiert auf Headless-Servern nicht) und kann ignoriert werden — der eigentliche Befehl läuft trotzdem durch.

Evaluierung: Apache2

Das httpd-Policy-Modul deckt Apache2 unter Debian standardmäßig ab.

Paket installieren
  • apt install apache2
  • systemctl restart apache2
Kontext prüfen
  • ps -eZ | grep apache2

Erwarteter Typ: httpd_t.

Vorhandene Port-Labels prüfen
  • semanage port -l | grep http_port_t

Custom Webroot einrichten

Verzeichnis anlegen
  • mkdir -p /srv/kurswebsite
  • mkdir -p /srv/kurswebsite/uploads
Testinhalt anlegen
  • echo "Kurswebsite it2XX" > /srv/kurswebsite/index.html
vHost anlegen
  • vim /etc/apache2/sites-available/kurswebsite.conf
<VirtualHost *:80>
    ServerName it2XX.int
    DocumentRoot /srv/kurswebsite
    <Directory /srv/kurswebsite>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
vHost aktivieren
  • a2ensite kurswebsite.conf
  • a2dissite 000-default.conf
  • systemctl reload apache2

Zugriff vor dem Labeling testen (Denial provozieren)

Test von der Kommandozeile

Erwartet an dieser Stelle: 403 Forbidden, obwohl die klassischen Unix-Rechte (Owner, Gruppe, Permissions) korrekt gesetzt sind — das Verzeichnis trägt noch keinen SELinux-Kontext für Apache.

Denial im Audit-Log bestätigen
  • ausearch -m avc -ts recent -c httpd
Aktuellen (falschen) Kontext ansehen
  • ls -Zd /srv/kurswebsite

Erwarteter (falscher) Typ an dieser Stelle: default_t oder var_t, je nach übergeordnetem Verzeichnis — jedenfalls nicht httpd_sys_content_t.

Kontext dauerhaft setzen

Niemals chcon verwenden, sondern dauerhaft über semanage fcontext:

  • semanage fcontext -a -t httpd_sys_content_t "/srv/kurswebsite(/.*)?"
  • restorecon -Rv /srv/kurswebsite
Kontext erneut prüfen
  • ls -Zd /srv/kurswebsite

Erwarteter Typ jetzt: httpd_sys_content_t.

Zugriff erneut testen

Erwartet: 200 OK.

Upload-Verzeichnis mit Schreibzugriff

Für das Unterverzeichnis uploads reicht Lesezugriff nicht — Apache soll dort schreiben dürfen (z. B. für eine Formularanwendung).

Eigenen Kontext für uploads setzen
  • semanage fcontext -a -t httpd_sys_rw_content_t "/srv/kurswebsite/uploads(/.*)?"
  • restorecon -Rv /srv/kurswebsite/uploads
Kontext prüfen
  • ls -Zd /srv/kurswebsite/uploads

Erwarteter Typ: httpd_sys_rw_content_t.

Boolean prüfen und ggf. setzen

Der Boolean httpd_unified hebt die Trennung zwischen Lese- und Schreibkontexten teilweise auf und sollte für dieses Szenario deaktiviert bleiben, damit die Trennung sichtbar bleibt:

  • getsebool httpd_unified
  • setsebool -P httpd_unified off
Schreibtest (z. B. über die Anwendung oder testweise als www-data)
  • sudo -u www-data touch /srv/kurswebsite/uploads/test.txt
  • ls -l /srv/kurswebsite/uploads/
Bei Fehlschlag
Denials prüfen
  • ausearch -m avc -ts recent -c httpd

HTTPS mit eigenem Zertifikat

Zertifikat und Key ablegen
  • ls -l /etc/ssl/own.crt /etc/ssl/own.key
SELinux-Kontext der Zertifikatsdateien prüfen
  • ls -Z /etc/ssl/own.crt /etc/ssl/own.key

Erwarteter Typ: cert_t, da /etc/ssl bereits standardmäßig darauf gelabelt ist. Falls die Dateien von woanders hierher kopiert wurden (statt z. B. per mv innerhalb von /etc/ssl verschoben), kann der Kontext vom Ursprungsort geerbt worden sein und muss korrigiert werden:

  • restorecon -v /etc/ssl/own.crt /etc/ssl/own.key
mod_ssl aktivieren
  • a2enmod ssl
vHost für Port 443 ergänzen
  • vim /etc/apache2/sites-available/kurswebsite.conf
<VirtualHost *:443>
    ServerName it2XX.int
    DocumentRoot /srv/kurswebsite
    SSLEngine on
    SSLCertificateFile /etc/ssl/own.crt
    SSLCertificateKeyFile /etc/ssl/own.key
    <Directory /srv/kurswebsite>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
Apache neu laden
  • systemctl reload apache2
Port-Label prüfen
  • semanage port -l | grep http_port_t

Port 443 ist im Standardzustand bereits als http_port_t gelabelt, üblicherweise ist hier kein manueller Eingriff nötig.

Zugriff testen
Bei Fehlschlag
Denials prüfen
  • ausearch -m avc -ts recent -c httpd

Häufigste Ursache bei SSL-Denials: der Boolean httpd_read_user_content oder ein falsch gelabelter Key/Cert-Pfad außerhalb von /etc/ssl bzw. /etc/pki. In dem Fall:

  • semanage fcontext -a -t cert_t "/etc/ssl/own\.(crt|key)"
  • restorecon -v /etc/ssl/own.crt /etc/ssl/own.key

Redirect von Port 80 auf 443

mod_rewrite aktivieren
  • a2enmod rewrite
Port-80-vHost auf Redirect umstellen
  • vim /etc/apache2/sites-available/kurswebsite.conf
<VirtualHost *:80>
    ServerName it2XX.int
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

<VirtualHost *:443>
    ServerName it2XX.int
    DocumentRoot /srv/kurswebsite
    SSLEngine on
    SSLCertificateFile /etc/ssl/own.crt
    SSLCertificateKeyFile /etc/ssl/own.key
    <Directory /srv/kurswebsite>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>
Apache neu laden
  • systemctl reload apache2
Redirect testen

Erwartet: 301 Moved Permanently mit Location: https://it2XX.int/.

Vollständigen Redirect-Durchlauf testen

Erwartet: erst 301, dann 200 OK nach dem Folgen des Redirects.

SELinux-seitig ist hier normalerweise kein weiterer Eingriff nötig, da beide Ports (80 und 443) bereits als http_port_t gelabelt sind und der Redirect selbst keine zusätzlichen Datei- oder Netzwerkzugriffe außerhalb des bestehenden httpd_t-Kontexts benötigt. Falls trotzdem ein Denial auftritt:

  • ausearch -m avc -ts recent -c httpd

Evaluierung: nginx

Für nginx existiert kein natives Policy-Modul in Debians selinux-policy-default. Zwei Optionen stehen zur Wahl:

  1. Community-Modul (z. B. simple10/selinux-nginx von GitHub) kompilieren und einspielen
  2. nginx unter dem bestehenden httpd_t-Kontext laufen lassen
Ist-Zustand nach Installation prüfen
  • apt install nginx
  • ps -eZ | grep nginx

Falls der Prozess als unconfined_t läuft oder Denials auftreten, ist das die erwartete Lücke, die dokumentiert werden soll.

Denials auswerten, falls vorhanden
  • ausearch -m avc -c nginx
  • audit2why -a

Vergleichstabelle (auszufüllen nach Testlauf)

Dienst Natives Policy-Modul Setup-Aufwand Ergebnis
sshd ja, automatisch niedrig
Apache2 ja, automatisch niedrig
nginx nein, nur Community mittel-hoch

Offene Punkte

  • nginx-Community-Modul testen und Ergebnis dokumentieren
  • Empfehlung für den Kurs formulieren, sobald alle drei Dienste durchgetestet sind
  • Vergleich mit dem AppArmor-Verhalten aus dem ursprünglichen Test (siehe Hintergrund) im Fazit gegenüberstellen
Abgerufen von „https://xinux.net/index.php?title=SELinux_auf_Debian&oldid=72309“