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 und Apache2, inklusive Apache als Reverse Proxy.

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 und Apache2 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

Reverse Proxy (ausgehender Verkehr)

Standardmäßig darf ein Apache-Prozess unter SELinux keine ausgehenden Netzwerkverbindungen zu einem Backend aufbauen — das betrifft klassisches mod_proxy, aber auch z. B. Verbindungen zu einem Datenbank- oder Applikationsserver.

Proxy-Module aktivieren

• a2enmod proxy
• a2enmod proxy_http

vHost mit Reverse Proxy anlegen

• vim /etc/apache2/sites-available/kurswebsite.conf

<VirtualHost *:80>
    ServerName proxy.it2XX.int
    ProxyPreserveHost On
    ProxyPass / http://192.168.2XX.10:8080/
    ProxyPassReverse / http://192.168.2XX.10:8080/
</VirtualHost>

vHost aktivieren

• a2ensite kurswebsite.conf
• systemctl reload apache2

Zugriff vor dem Boolean testen (Denial provozieren)

Test von der Kommandozeile

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

Erwartet an dieser Stelle: 503 Service Unavailable, obwohl das Backend selbst erreichbar ist — Apache darf noch keine ausgehende Verbindung aufbauen.

Denial im Audit-Log bestätigen

• ausearch -m avc -ts recent -c httpd

Erwartete Meldung u. a.: Zugriff verweigert für httpd_t auf name_connect.

Boolean für ausgehenden Verkehr setzen

Aktuellen Zustand prüfen

• getsebool httpd_can_network_connect

Boolean dauerhaft aktivieren

• setsebool -P httpd_can_network_connect on

Zugriff erneut testen

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

Erwartet: 200 OK, sofern das Backend erreichbar ist und selbst korrekt antwortet.

Bei Fehlschlag

Denials erneut prüfen

• ausearch -m avc -ts recent -c httpd

Hinweis: Falls das Backend auf einem ungewöhnlichen Port läuft (hier 8080) und dieser nicht bereits als http_port_t, http_cache_port_t o. ä. gelabelt ist, kann zusätzlich ein gezielterer Boolean nötig sein, z. B. httpd_can_network_connect_db bei Datenbank-Backends statt des pauschalen httpd_can_network_connect. Für den Kurs reicht der allgemeine Boolean als Einstieg, sollte aber als Beispiel für "möglichst granular statt pauschal erlauben" erwähnt werden.

Vergleichstabelle (auszufüllen nach Testlauf)

Dienst / Szenario	Natives Policy-Modul	Setup-Aufwand	Ergebnis
sshd	ja, automatisch	niedrig
Apache2 (Webroot, HTTPS)	ja, automatisch	niedrig
Apache2 als Reverse Proxy	ja, über Boolean	niedrig

Offene Punkte

• Empfehlung für den Kurs formulieren, sobald sshd, Apache2 und Reverse Proxy durchgetestet sind
• Vergleich mit dem AppArmor-Verhalten aus dem ursprünglichen Test (siehe Hintergrund) im Fazit gegenüberstellen