SELinux auf Debian

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.

Enforcing-Modus prüfen

Wie bei Rocky wird direkt im enforcing Modus gearbeitet, kein Umweg über permissive:

• getenforce

Erwartet: Enforcing (Standard nach der Aktivierung). Falls nicht, dauerhaft in /etc/selinux/config setzen:

SELINUX=enforcing

und neu starten.

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

• curl -I http://it2XX.int/

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

• curl -I http://it2XX.int/

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

• curl -Ik https://it2XX.int/

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

• curl -I http://it2XX.int/

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

Vollständigen Redirect-Durchlauf testen

• curl -IL http://it2XX.int/

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