SELinux auf Debian - Versionsgeschichte

Thomas.will: /* Offene Punkte */

2026-07-28T17:17:31Z

Offene Punkte

Thomas.will am 28. Juli 2026 um 17:17 Uhr

2026-07-28T17:17:02Z

Thomas.will am 28. Juli 2026 um 17:14 Uhr

2026-07-28T17:14:48Z

Thomas.will am 28. Juli 2026 um 17:09 Uhr

2026-07-28T17:09:36Z

Änderungen zeigen

Thomas.will: /* Evaluierung: sshd */

2026-07-28T17:02:39Z

Evaluierung: sshd

Thomas.will: Die Seite wurde neu angelegt: „= SELinux statt AppArmor auf Debian = Diese Seite dokumentiert die Migration von AppArmor zu SELinux auf it2XX und die anschließende Evaluierung für sshd, A…“

2026-07-28T12:56:16Z

Die Seite wurde neu angelegt: „= SELinux statt AppArmor auf Debian = Diese Seite dokumentiert die Migration von AppArmor zu SELinux auf it2XX und die anschließende Evaluierung für sshd, A…“

Neue Seite

= 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 <code>apparmor-profiles-extra</code> 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 <code>aa-logprof</code>-Durchläufe nachgezogen werden
* <code>aa-logprof</code> 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 <code>abstractions/apache2-common</code> 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 <code>/etc/default/grub</code> ergänzen:

<pre>
GRUB_CMDLINE_LINUX_DEFAULT="... apparmor=0"
</pre>

;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 <code>/etc/selinux/config</code>:

<pre>
SELINUX=enforcing
</pre>

== 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: <code>sshd_t</code> für den Prozess, <code>sshd_exec_t</code> für die Binary.

;Denials nach Testlogin auswerten
*ausearch -m avc -c sshd

== 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

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

;Custom Webroot freischalten (Beispiel /srv/kurswebsite)

Niemals <code>chcon</code> verwenden, sondern dauerhaft über <code>semanage fcontext</code>:

*semanage fcontext -a -t httpd_sys_content_t "/srv/kurswebsite(/.*)?"
*restorecon -Rv /srv/kurswebsite

;Boolean für Schreibzugriff (z. B. Upload-Verzeichnis)
*setsebool -P httpd_unified off
*semanage fcontext -a -t httpd_sys_rw_content_t "/srv/kurswebsite/uploads(/.*)?"
*restorecon -Rv /srv/kurswebsite/uploads

== Evaluierung: nginx ==

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

# Community-Modul (z. B. simple10/selinux-nginx von GitHub) kompilieren und einspielen
# nginx unter dem bestehenden <code>httpd_t</code>-Kontext laufen lassen

;Ist-Zustand nach Installation prüfen
*apt install nginx
*ps -eZ | grep nginx

Falls der Prozess als <code>unconfined_t</code> 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) ==

{| class="wikitable"
! 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

← Nächstältere Version		Version vom 28. Juli 2026, 17:17 Uhr
Zeile 377:		Zeile 377:
	\| Apache2 als Reverse Proxy \|\| ja, über Boolean \|\| 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

@@ Zeile 1: / Zeile 1: @@
 = 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.
+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 ==
@@ Zeile 12: / Zeile 12: @@
 * Die generierten Vorschläge waren teils unpassend (z. B. Vorschlag von <code>abstractions/apache2-common</code> 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.
+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 ==
@@ Zeile 312: / Zeile 312: @@
 *ausearch -m avc -ts recent -c httpd
-== Evaluierung: nginx ==
+=== Reverse Proxy (ausgehender Verkehr) ===
-Für nginx existiert '''kein''' natives Policy-Modul in Debians <code>selinux-policy-default</code>. Zwei Optionen stehen zur Wahl:
+Standardmäßig darf ein Apache-Prozess unter SELinux keine ausgehenden Netzwerkverbindungen zu einem Backend aufbauen — das betrifft klassisches <code>mod_proxy</code>, aber auch z. B. Verbindungen zu einem Datenbank- oder Applikationsserver.
-# Community-Modul (z. B. simple10/selinux-nginx von GitHub) kompilieren und einspielen
+;Proxy-Module aktivieren
-# nginx unter dem bestehenden <code>httpd_t</code>-Kontext laufen lassen
+*a2enmod proxy
-;Ist-Zustand nach Installation prüfen
+;vHost mit Reverse Proxy anlegen
-*apt install nginx
+*vim /etc/apache2/sites-available/kurswebsite.conf
-Falls der Prozess als <code>unconfined_t</code> läuft oder Denials auftreten, ist das die erwartete Lücke, die dokumentiert werden soll.
+<pre>
-;Denials auswerten, falls vorhanden
+'''Hinweis:''' Falls das Backend auf einem ungewöhnlichen Port läuft (hier 8080) und dieser nicht bereits als <code>http_port_t</code>, <code>http_cache_port_t</code> o. ä. gelabelt ist, kann zusätzlich ein gezielterer Boolean nötig sein, z. B. <code>httpd_can_network_connect_db</code> bei Datenbank-Backends statt des pauschalen <code>httpd_can_network_connect</code>. 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) ==
 {| class="wikitable"
-! Dienst !! Natives Policy-Modul !! Setup-Aufwand !! Ergebnis
+! Dienst / Szenario !! Natives Policy-Modul !! Setup-Aufwand !! Ergebnis
 |-
 | sshd || ja, automatisch || niedrig ||
 |-
-| Apache2 || ja, automatisch || niedrig ||
+| Apache2 (Webroot, HTTPS) || ja, automatisch || niedrig ||
 |-
-| nginx || nein, nur Community || mittel-hoch ||
+| Apache2 als Reverse Proxy || ja, über Boolean || niedrig ||
 |}
 == Offene Punkte ==
-* nginx-Community-Modul testen und Ergebnis dokumentieren
+* 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

@@ Zeile 49: / Zeile 49: @@
 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
+;Enforcing-Modus prüfen
-*setenforce 0
 *getenforce
-Erst nach erfolgreicher Prüfung aller Dienste auf enforcing umstellen, in <code>/etc/selinux/config</code>:
+Erwartet: <code>Enforcing</code> (Standard nach der Aktivierung). Falls nicht, dauerhaft in <code>/etc/selinux/config</code> setzen:
 <pre>
 SELINUX=enforcing
 </pre>
 == Evaluierung: sshd ==

@@ Zeile 74: / Zeile 74: @@
 ;Denials nach Testlogin auswerten
 *ausearch -m avc -c sshd
 == Evaluierung: Apache2 ==