Zwei Moodle Unterbrueche in der letzten Woche

[Daniel Baumann]

Hallo zusammen,

die vergangene Woche gab es zwei Moodle Unterbrueche:

  * Montag, 19.12.2016:  07:47 bis 08:01
  * Freitag, 23.12.2016: 19:31 bis Samstag, 24.12. 11:54

Kurze Erklaerung:

  * Moodle laeuft innerhalb eines Linux Containers. Der Container laeuft
    auf einem sogenannten Container Server.

  * Die Container Management-Tools haben eine sicherheitsrelevante
    Einstellung fuer das Verzeichnis, welches alle Container Dateien
    enthaelt.

  * Fuer beide Ausfaelle war eine zu restriktive, sicherheitsrelevante
    Standardeinstellung fuer das Container Verzeichnis verantwortlich.
    Der Effekt war dass der Webserver die Moodle Dateien nicht lesen
    und daher waehrend der angegebenen Zeitraeume die Moodle Webseite
    nicht benutztbar war.

  * Die Einstellung ist korrigiert, das Problem wird nicht mehr wieder
    auftreten.




Lange (technische) Erklaerung:

  * Auf dem Container Server liegen alle Container unter /srv/container
    auf dem Dateisystem (resp. /srv/container ist der Mountpoint des
    NetApp Shares).

  * Im allgemeinen Fall gilt:
    - Wenn unprivilierte User sich auf dem Container Server anmelden
      koennten, und das Container Verzeichnis (/srv/container) fuer
      diese les- und ausfuehrbar ist (Mode 0755 resp. rwxr-xr-x, was
      den Standart-Permissions fuer ein Verzeichnis enspricht), koennen
      diese in die Container Root Verzeichnises hinein (z.B.
      /srv/container/example.bfh.ch).
    - Die ist grundsaetzlich nicht erwuenscht: einerseits koennten so
      Dateien gelesen werden die nur User des Containers lesbar sein
      sollten, anderer seits im Falle von gleichen UIDs (z.B. User
      foo/1000 auf dem Container Server koennte zufaelligerweise dem
      User bar/1000 im Container ensprechen) koennen sogar Daten im
      Container vom Container Server aus geloescht werden
      (z.B. /srv/container/example.bfh.ch/home/foo).
    - Um dies zu verhindern, setzt man standardmaessig das Container
      Verzeichnis auf root-only (d.h. Mode 0700 resp. rwx------). Damit
      wird oben beschriebens Problem ausgeschlossen und das
      manipulieren von Container Files vom Container Server aus ist nur
      durch root moeglich.
    - container-tools (CNT) implementiert dies als sichere
      Standardeinstellung, solange diese nicht mit dpkg-statoveride
      lokal ueberschrieben wird, wird bei jedem dpkg-reconfigure oder
      dpkg --configure dies wieder hergestellt:
      -> siehe ensprechende Code Zeile:

https://sources.debian.net/src/open-infrastructure-container-tools/20161101-lts2-1/debian/open-infrastructure-container-tools.postinst/#L28
      -> resp. der Commit der Aenderung damals:

https://sources.progress-linux.org/users/daniel/debian/packages/open-infrastructure-container-tools/commit/?id=6306bdcc6383d13b3db6108af44051507d19d92e
    - LXC macht das bis heute leider nicht und ist by default angreifbar
      (ja, wenn ich mal Zeit haette wuerd ich ein CVE Submission machen
      dafuer).

  * Als wir im Juli von die Container Management-Tools weg von LXC hin
    zu CNT migriert haben, haetten wir:
    - einerseits das NetApp Share sinnvollerweise neu strukturieren
      sollen.
    - andererseits das Moodle Share welches aus anderen Gruenden noch
      anderst aufgebaut ist, mit den anderen "normalen" Container
      Shares harmonisieren sollen.
    - Beides haben wir aus Zeitgruenden leider immer wieder nach hinten
      schieben muessen. Geplant ist schon laenger, dies waehrend der
      seit Mitte Dezember laufenden Upgrades aller Container Server auf
      Debian 9 (stretch) bis Ende Januar 2017 abzuschliessen.

  * Konkret fuer BFH summieren sich dann folgende Dingen zusaetzlich
    auf:
    - Im Moodle Container Server Fall befindet sich wegen anderem
      NetApp Layout der Mountpoint nicht unter /srv/container, sondern
      unter /mnt/nfs/moodle.
      Grund: Daten und Container liegen aus Performance Gruenden auf
      dem gleichen, schnelleren Share (beide SAS), statt wie normal auf
      zwei unterschiedlichen (Container auf SAS, Daten auf SATA).
    - Da nspawn (berechtigterweise) keine Symlinks als root
      Verzeichnisse (z.B. /srv/container/example.bfh.ch) fuer Container
      akzeptiert, muss das darueber liegende Verzeichnis
      (/srv/container) gesymlinkt sein.
      Es zeigt also /srv/container nach /mnt/nfs/moodle/[...].
    - Ohne dpkg-statoverride wird /srv/container auf 700
      zurueckgesetzt, und damit sind die Daten fuer den Container nicht
      mehr lesbar. Dies geschiet automatisch in gewissen interfallen,
      namentlich immer beim einspielen jeglicher (Security) Updates.

  * Abhilfe (und warum das Problem nicht mehr auftauchen wird):
    - einerseits haben wir temporaer auf dem Moodle Container Server per
      dpkg-statoverride die Permissions gesetzt, diese werden von den
      Container Management-Tools nicht wieder zurueckgesetzt.
    - andererseits wird ab Januar 2017 unser neue Monitoring
      Infrastruktur fuer LFE Dienste dies ueberwachen und sofort
      alarmieren.

Wir entschuldigen uns fuer die beiden Ausfaelle und wuenschen bei
dieser Gelegenheit allen weiterhin frohe Festtage und einen guten Rutsch.

Gruesse,
Daniel

-- 
Berner Fachhochschule / Bern University of Applied Sciences
IT-Services / Team Infrastructure Services
Daniel Baumann
IT System Engineer Linux
___________________________________________________________
Dammweg 3, CH-3013 Bern
Phone direct +41 31 848 48 22
Phone Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://servicedesk.bfh.ch
https://www.bfh.ch
https://linux.bfh.ch