ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Praxistest

Um zu überprüfen, inwieweit aktuelle Betriebssysteme unter Nutzung von Secure Boot auf den ausgewählten Hardware-Plattformen lauffähig sind, wurden sie auf jeder Plattform testweise installiert. Es wurde ferner überprüft, ob das System nach der Installation ordnungsgemäß startet und somit grundsätzlich funktionstüchtig ist.

Sofern das jeweilige Betriebssystem Secure Boot unterstützt, haben wir dessen Umsetzung analysiert. Ist eine Unterstützung von Secure Boot nicht gegeben, so wurden zusätzliche Schritte geprüft, die das System bei aktivem Secure Boot einsetzbar machen. Hierbei steht die Funktionstüchtigkeit im Vordergrund. Auf eine weitergehende Beurteilung wird verzichtet. Die getesteten Betriebssysteme sind:

  • Microsoft Windows 8 Pro
  • Red Hat Enterprise Linux 6.4
  • Ubuntu 13.04
  • Debian 7.1.0
  • Fedora 19
  • FreeBSD 9.2

Ergebnisse

Trotz der relativ neuen Technik und der umfangreichen Spezifikation arbeitet Secure Boot auf allen untersuchten Plattformen mit den eingesetzten Betriebssystemen zusammen. Das Starten einer signierten UEFI-Anwendung wie etwa eines Bootloaders funktioniert, sofern das entsprechende Zertifikat in dem db-Zertifikatsspeicher der UEFI-Firmware enthalten ist. Auch wird der Start einer solchen Anwendung verweigert, sofern kein passendes Zertifikat in diesem Zertifikatsspeicher vorhanden ist. Ebenso funktioniert die Verifikation von UEFI-Anwendungen anhand von Hashes problemlos.

Ferner ist die Installation und der Betrieb der Betriebssysteme Windows 8 Pro, Ubuntu 13.04 und Fedora 19 bei aktiviertem Secure Boot möglich. Die ebenfalls untersuchten Betriebssysteme Red Hat Enterprise Linux 6.4, FreeBSD 9.2 und Debian 7.1.0 unterstützen Secure Boot nicht und werden daher bei deaktiviertem Secure Boot installiert. Sie lassen sich jedoch mit relativ geringem Aufwand so modifizieren, dass sie auch bei aktivem Secure Boot laufen können.

Bei der Integration von Secure Boot und dem daraus resultierenden Gewinn an Sicherheit gibt es jedoch gravierende Unterschiede. Ebenso ist der Sicherheitsgewinn bei dem Einsatz von Ubuntu 13.04 gering. Zwar werden die Bootloader verifiziert, eine effektive Überprüfung des Kernels samt seiner Module findet jedoch nicht statt.

Im Gegensatz hierzu findet bei Fedora 19 nicht nur eine Verifikation der Bootloader, sondern auch des Kernels und seiner Module statt.

FreeBSD plant eine ähnliche Umsetzung, wie sie bereits Fedora nutzt. Wenngleich Windows 8 Pro ebenfalls eine Überprüfung des Bootloaders und des Kernels durchführt, ist eine Beurteilung der Effektivität der Schutzmaßnahmen erheblich schwieriger als bei den untersuchten Linux-Systemen. Grund ist hierfür hauptsächlich das komplexe Vorgehen zur Verifikation von nachträglich zu ladenden Kernelkomponenten wie zum Beispiel Treibern. Microsoft setzt hier zur Erkennung von Schadsoftware auf eine Zusammenarbeit des Kernels mit Anti-Malware-Produkten.

Die Effektivität der Schutzfunktionen hängt daher ganz erheblich von der Qualität des eingesetzten Produktes ab. Auch wird die von Microsoft neu eingeführte ELAM-Technik im Rahmen dieser Arbeit auf Grund ihrer Komplexität nicht bewertet. Ferner bieten die nachfolgend für Debian 7.1.0 aufgeführten Änderungen, die analog für Red Hat Enterprise 6.4 und FreeBSD 9.2 durchgeführt werden können, nur einen geringen Sicherheitsgewinn. Die Ergebnisse dieser Tests sind in Tabelle 2 zusammengefasst.

Tabelle 2

Testergebnisse

 

Windows 8 Pro

Red Hat Enterprise Linux 6.4

Debian 7.1.0

FreeBSD 9.2

Ubuntu 13.04

Fedora 19

Wird Secure Boot im Betrieb unterstützt?

Ja

Nein

Nein

Nein

Ja

Ja

Wird Secure Boot bei der Installation unterstützt?

Ja

Nein

Nein

Nein

Ja

Ja

Ist eine nachträgliche Unterstützung durch Shim möglich?

-

Ja

Ja

Ja

-

-

Effektiver Umfang der Verifikationskette

Bootloader, Kernel (bedingt)

Shim

Shim

Shim

Shim, Grub

Shim, Grub2, Kernel, Kernelmodule

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020