RHEL / CentOS 7.4
Mit dem Update auf CentOS 7.4 gibt es einige Veränderungen des Verhaltens von SELinux gegenüber Tomcat:
- Der File-Context von WAR-Files wird beachtet
- Datenbankverbindungen werden untersagt
- Verbindungen zu SMTP-Servern werden untersagt
- NFS-Zugriffe werden untersagt
- Zugriffe auf das Dateisystem werden untersagt
Zu 1.)
Damit alle Applikationen auch nach dem Update funktionieren, muss zukünftig darauf geachtet werden, dass WAR-Files nicht in das webapps-Verzeichnis verschoben werden. Diese sollten also in das Verzeichnis kopiert werden.
Das Problem beim Verschieben ist, dass der möglicherweise falsche SELinux File-Context des Quellverzeichnisses erhalten bleibt. Beim Kopieren ist das nicht der Fall.
Alternativ kann der Filecontext auch mittels dem Befehl
[root@sds ~]# restorecon -rv /usr/share/tomcat/webapps |
auf den Standard des Verzeichnisses korrigiert werden.
In den Tomcat-Logs äußert sich ein falscher File-Context folgendermaßen:
java.io.FileNotFoundException: /var/lib/tomcat/webapps/oauth.war |
Zu 2. & 3.)
Möglichkeit 1 - Regeln selbst erstellen:
Die API des DRACOONs bildet nochmals einen Sonderfall, da diese eine Datenbankverbindung aufbauen muss. Ebenso müssen E-Mails versendet werden können.
Damit diese nicht durch SELinux geblockt wird, setzen wir dieses nach dem Update auf CentOS 7.4 und dem anschließenden Neustart auf permissive und starten den Tomcat neu:
[root@sds ~]# setenforce 0 |
Wenn die Applikation vollständig gestartet wurde, muss eine entsprechende Policy für SELinux erstellt werden (hierzu muss das Paket "policycoreutils-python" installiert sein):
[root@sds ~]# grep tomcat /var/log/audit/audit.log | audit2allow -m tomcat_mysql require { #============= tomcat_t ============== semodule -i tomcat_mysql.pp |
ACHTUNG: Mit ausschließlich dieser Regel ist der DRACOON noch nicht voll funktionsfähig. Um eine vollständige Regel selbst zu generieren, muss jede Funktion des DRACOONs (hochladen, herunterladen, löschen, Mail versenden,...) einmal ausgeführt werden.
Anschließend kann SELinux wieder in den Enforcing-Mode versetzt werden und der Start des Tomcat nochmals getestet werden:
[root@sds ~]# setenforce 1 |
Für alles Weitere (STMP, NFS, ...) ist das Vorgehen identisch und kann auch in einer Regel kombiniert werden.
Bei der Nutzung eines NFS-Shares sähe eine Regel wie folgt aus:
[root@sds ~]# grep tomcat /var/log/audit/audit.log | audit2allow -m tomcat_nfs require { #============= tomcat_t ============== |
Möglichkeit 2 - Regeln übernehmen:
Die untenstehenden Regeln können auch übernommen und auf dem System aktiviert werden.
Die untenstehende Policy wird in ein entsprechendes Textfile auf dem System kopiert.
Anschließend erstellen und aktivieren wir die Policy (hierzu muss das Paket "policycoreutils-python" installiert sein):
[root@sds ~]# checkmodule -M -m -o policy.mod policy.te |
tomcat_mysql.te:
require { #============= tomcat_t ============== |
tomcat_nfs.te:
require { #============= tomcat_t ============== |
tomcat_mnt.te (wenn die Daten nicht auf einem NFS Share sondern unter /mnt/ liegen - hier muss auf den richtigen Filecontext geachtet werden, z.B. 'chcon -R -u system_u -r object_r -t mnt_t /mnt/data'):
require { #============= tomcat_t ============== |
tomcat_smtp.te:
require { #============= tomcat_t ============== |
Kommentare
0 Kommentare
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.