Öfters erscheint im ersten Moment eine Überprüfung des Regelwerkes von SELinux als absolut richtig und der Fehler lässt sich trotz Argusaugen nicht finden. Hier kann audit2why helfen den Wald unter all den Bäumen zu finden und eine aufkommende Trichotillomanie abzuwehren.
audit2why und audti2allow
Bei audit2why handelt es sich um den auf der Programmiersprache Python geschriebenen Parser und „Bruder“ von audit2allow aus dem Paket der policycoreutils für SELinux.
audit2why übersetzt die Auditnachrichten anhand der Logdateien und gibt Auskunft darüber warum einem Prozess der Zugriff verweigert wurde.
audit2allow erstellt benutzerdefinierte Regeln für SELinux anhand der Logdateien für Prozesse deren Zugriff verweigert wurden. Hiermit lassen sich Regeln erstellen um den Zugriff zu erlauben, oder um sie zu negieren, den Zugriff zu verbieten.
Ein Blick in die Dokumentation von beiden Werkzeugen ist sehr erhellend.
Zufallsfund audit2why
Ich bin zu audit2why eher durch einen Zufall gekommen. Da mein Server jedes Schreibrecht auf das Verzeichnis data in Owncloud verweigerte. Sei es der Weg über die nativen Clients von Owncloud, oder auch nur per webDAV.
Hier muss man vorab Wissen, dass CentOS ein paar Tage zuvor ein Upgrade auf die neue Version 7.1, oder wie man es nimmt, auch 7.0 ( 1503) bekam. Danach lief eigentlich alles weiterhin rund. Das Logfile von Owncloud wurde von meiner Seite natürlich nach problematischen Einträgen untersucht. Einzig ein Eintrag im Fahrwasser, betreffend sabreDAV, erregte meine Aufmerksamkeit und brachte mir neues Fachwissen zu dem Backend von Owncloud. Aber keinen Lösungsansatz zu dem betreffenden Problem.
Hier muss ich auf jeden Fall auf eine später erschienene tolle Reihe über sabre/dav auf dem Blog von Owncloud zu dem Thema sabre/dav verweisen, welche mir die Tage zuvor doch einiges erleichtert hätte. Eine Leseempfehlung für jeden Owncloudadministrator.
- Sabre/dav stellte sich somit natürlich nicht als der ursprüngliche Fehler heraus.
Eine nochmalige Überprüfung der Datei- und Ordnerrechte brachte keine Lösung. - An den Reglement betreffend SEL wurde von meiner Seite aus nicht geschraubt.
- Smartd ist der Meinung, dass die Festplatten noch in Ordnung sind
- und es war auch kein Einbruch auf der Maschine war zu verzeichnen.
Ich rechne immer mit dem worst case am Server und nutze alle Möglichkeiten um den Fehler einzukreisen.
Leider war der Fehler nicht aufzufinden und ich überschlief erst einmal die Sache um einen pebcac auszuschließen. Natürlich könnte ich mich gleich Baikal und Seafile zuwenden, aber mir ist Lösung des Fehlers und der damit verbundenen Umstände wirklich sehr wichtig und lässt mich nicht in Ruhe.
Nach dem nochmaligen abschalten von SELinux und einem Neustart des Server konnte ich wieder mit jeder Plattform und dem dazugehörigen Clients einen Upload vornehmen und der Schuldige war hier nicht bei Owncloud zu suchen.
Nur warum?
Ich hatte alle Regeln überprüft und sie auch nicht geändert, alle Regeln waren in dem richtige Kontext, wurden nochmals gelöscht und per:
semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/data' && restorecon '/var/www/data' && chown apache:apache /var/www/data/ && chmod -R 775 /var/www/data/
wiederum an SELinux übergeben.
Eine Überprüfung des gesetzten Reglements ergab, dass die Konfiguration richtig übernommen wurde.
semanage fcontext -l |grep /var/www/data /var/www/data all files system_u:object_r:httpd_sys_rw_content_t:s0
Ein Scharf schalten von SELinux brachte mir wieder den gewohnten Fehler.
Ein Tip auf Google+ brachte mich später auf das mir noch unbekannte Werkzeug audit2why.
audit2why schlüsselt SELinux auf
audit2why findet sich bei centOS/RedHat in dem Paket policycoreutils-python, bei Debian muss das Paket policycoreutils installiert werden/sein.
Nachdem ich das Log an den parser autid2why übergeben hatte, gab mir dieser auch gleich die passende Antwort zu meinem Problem:
audit2why < /var/log/audit/audit.log httpd" name="photosync" dev="sda5" ino=9052784 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file Was caused by: The boolean httpd_unified was set incorrectly. Description: Allow httpd to unified Allow access by executing: # setsebool -P httpd_unified 1
httpd_unified stand leider nicht auf on, sondern auf off. Somit erlaubte ich dem httpd nicht alle Dateien als seine zu betrachten und zu bearbeiten.
Siehe dazu auch die Manpage httpd_selinux(8) :
If you want to unify HTTPD handling of all content files, you must turn on the httpd_unified boolean.
setsebool -P httpd_unified 1
Nach dem setzen des richtigen Wertes und der Überprüfung konnte ich wieder die mir nötigen Verzeichnisse beschreiben.
[root@got-tty ~]# sestatus -b | grep httpd | grep on$ httpd_builtin_scripting on httpd_enable_cgi on httpd_graceful_shutdown on httpd_unified on
Fazit
Manchmal sieht man den Wald vor lauter Bäumen nicht. Es ist sehr wichtig dann die richtigen Werkzeuge zur Hand zu haben. Diese können hier helfen und auf Problematiken hinweisen. Diesmal war der Fehler marginal , dass nächste mal könnte er nicht so schlicht ausgehen.
Nach einem Upgrade von SELinux unter centOS sollte man nochmals die kompletten Einstellungen überprüfen und der Fehler war somit ein pebkac. Wenn ich schon oben im zweiten Absatz von einem Upgrade schreibe, dann …
Danke nochmal an Lukas Grossar für den wirklich guten Tipp
Immer schön, wenn man die Fehler sucht und nicht einfach den einfachen Weg geht. Danke dafür.