Hardening der Virtualisierungsschichten¶
In the beginning of this chapter we discuss the use of both physical and virtual hardware by instances, the associated security risks, and some recommendations for mitigating those risks. Then we discuss how the Secure Encrypted Virtualization technology can be used to encrypt the memory of VMs on AMD-based machines which support the technology. We conclude the chapter with a discussion of sVirt, an open source project for integrating SELinux mandatory access controls with the virtualization components.
Physikalische Hardware (PCI Passthrough)¶
Viele Hypervisoren bieten eine Funktionalität, die als PCI-Passthrough bekannt ist. Dies ermöglicht eine Instanz direkten Zugriff auf ein Stück Hardware auf dem Knoten. Zum Beispiel könnte dies verwendet werden, um Instanzen zu ermöglichen, auf Videokarten oder GPUs zuzugreifen, die die Berechnungseinheit der Unified Device Architecture (CUDA) für die Hochleistungsberechnung anbieten. Diese Funktion trägt zwei Arten von Sicherheitsrisiken: direkter Speicherzugriff und Hardwareinfektion.
Der Direktspeicherzugriff (DMA) ist ein Merkmal, das es bestimmten Hardwaregeräten ermöglicht, auf beliebige physikalische Speicheradressen im Hostcomputer zuzugreifen. Oft haben Grafikkarten diese Fähigkeit. Jedoch sollte eine Instanz keinen willkürlichen physischen Speicherzugriff erhalten, da dies eine vollständige Ansicht sowohl des Host-Systems als auch anderer Instanzen, die auf demselben Knoten laufen, geben würde. Hardware-Hersteller verwenden eine Input/Output-Speicherverwaltungseinheit (IOMMU), um den DMA-Zugriff in diesen Situationen zu verwalten. Wir empfehlen Cloud-Architekten sicherzustellen, dass der Hypervisor konfiguriert so ist, um diese Hardware-Funktion zu nutzen.
Bemerkung
Die IOMMU-Funktion wird von Intel und AMD-Vi von AMD als VT-d vermarktet.
Eine Hardware-Infektion tritt auf, wenn eine Instanz eine bösartige Änderung an der Firmware oder einem anderen Teil eines Geräts vornimmt. Da dieses Gerät von anderen Instanzen oder dem Host-Betriebssystem verwendet wird, kann sich der bösartige Code in diese Systeme verteilen. Das Endergebnis ist, dass eine Instanz Code außerhalb ihrer Sicherheitsdomäne ausführen kann. Dies ist eine signifikante Verletzung, da es schwieriger ist, den Zustand der physischen Hardware als die virtuelle Hardware zurückzusetzen und kann zu einer zusätzlichen Belichtung wie dem Zugriff auf das Verwaltungsnetzwerk führen.
Lösungen für das Hardware-Infektionsproblem sind domänenspezifisch. Die Strategie besteht darin, zu identifizieren, wie eine Instanz den Hardware-Status ändern kann, um zu bestimmen, wie man irgendwelche Änderungen zurücksetzt, wenn die Instanz mit der Hardware durchgeführt wird. Zum Beispiel könnte eine Option sein, um die Firmware nach Gebrauch wieder zu re-flashen. Es besteht die Notwendigkeit, die Hardware-Langlebigkeit mit der Sicherheit auszugleichen, da einige Firmware nach einer großen Anzahl von Schreibvorgängen scheitern werden. TPM-Technologie, beschrieben in Sicheres Bootstrapping, ist eine Lösung für die Erkennung nicht autorisierter Firmware-Änderungen. Unabhängig von der gewählten Strategie ist es wichtig, die mit dieser Art von Hardware-Sharing verbundenen Risiken zu verstehen, damit sie für ein bestimmtes Bereitstellungsszenario ordnungsgemäß gemildert werden können.
Aufgrund des Risikos und der Komplexität, die mit dem PCI-Passthrough verbunden ist, sollte es standardmäßig deaktiviert werden. Wenn es für einen bestimmten Bedarf aktiviert ist, müssen Sie entsprechende Prozesse an Ort und Stelle haben, um sicherzustellen, dass die Hardware vor der Neuausgabe sauber ist.
Virtuelle Hardware (QEMU)¶
Beim Ausführen einer virtuellen Maschine ist virtuelle Hardware eine Software-Schicht, die die Hardware-Schnittstelle für die virtuelle Maschine bereitstellt. Instanzen verwenden diese Funktionalität, um Netzwerk-, Speicher-, Video- und andere Geräte bereitzustellen, die benötigt werden können. In diesem Sinne werden die meisten Instanzen in Ihrer Umgebung ausschließlich virtuelle Hardware verwenden, mit einer Minderheit, die einen direkten Hardwarezugriff erfordert. Die wichtigsten Open-Source-Hypervisoren :term:`QEMU <Quick EMUlator (QEMU)>`für diese Funktionalität. Während QEMU einen wichtigen Bedarf an Virtualisierungsplattformen erfüllt, hat es sich als ein sehr anspruchsvolles Softwareprojekt erwiesen, was zuschreiben und zu pflegen ist. Ein Großteil der Funktionalität in QEMU wird mit Low-Level-Code implementiert, der für die meisten Entwickler schwer zu verstehen ist. Die Hardware, die von QEMU virtualisiert wird, enthält viele ältere Geräte, die ihren eigenen Satz von Macken haben. Das alles zusammen, QEMU war die Quelle für viele Sicherheitsprobleme, einschließlich Hypervisor Breakout-Angriffe.
Es ist wichtig, proaktive Schritte zu unternehmen, um QEMU zu verhärten. Wir empfehlen drei spezifische Schritte:
Minimierung der Codebasis.
Mit Compiler Hardening.
Verwenden Sie obligatorische Zugriffskontrollen wie sVirt, SELinux oder AppArmor.
Stellen Sie sicher, dass Ihre iptables die Standardrichtlinienfilterung des Netzwerkverkehrs haben und prüfen Sie die vorhandene Regelmenge, um jede Regel zu verstehen und festzustellen, ob die Richtlinie erweitert werden muss.
Minimierung der QEMU-Codebasis¶
Wir empfehlen, die QEMU-Codebasis zu minimieren, indem wir unbenutzte Komponenten aus dem System entfernen. QEMU bietet Unterstützung für viele verschiedene virtuelle Hardware-Geräte, aber nur eine kleine Anzahl von Geräten werden für eine gegebene Instanz benötigt. Die gängigsten Hardwaregeräte sind die virtio Geräte. Einige Legacy-Instanzen benötigen Zugriff auf spezifische Hardware, die mit Glance-Metadaten angegeben werden kann:
$ glance image-update \
--property hw_disk_bus=ide \
--property hw_cdrom_bus=ide \
--property hw_vif_model=e1000 \
f16-x86_64-openstack-sda
Ein Cloud-Architekt sollte entscheiden, welche Geräte für Cloud-User zur Verfügung stehen. Alles, was nicht benötigt wird, sollte aus QEMU entfernt werden. Dieser Schritt erfordert das Neukompilieren von QEMU nach dem Ändern der an das QEMU-Skript übergebenen Optionen. Für eine vollständige Liste der aktuellen Optionen starten Sie einfach ./configure --help aus dem QEMU-Quellverzeichnis. Entscheiden Sie, was für Ihre Bereitstellung benötigt wird, und deaktivieren Sie die verbleibenden Optionen.
Compiler Hardening¶
QEMU härten mit Compiler-Härtungsoptionen. Moderne Compiler bieten eine Vielzahl von Kompilierzeitoptionen, um die Sicherheit der resultierenden Binärdateien zu verbessern. Zu diesen Merkmalen gehören Relocation-Read-only (RELRO), Stack-Canaries, never execute (NX), position independent executable (PIE) und address space layout randomization (ASLR).
Viele moderne Linux-Distributionen bauen bereits QEMU mit aktiviertem Compiler Hardening, wir empfehlen Ihnen, Ihre vorhandene ausführbare Datei zu überprüfen, bevor Sie fortfahren. Ein Werkzeug, das Sie bei dieser Überprüfung unterstützen kann, heißt checksec.sh <http://www.trapkit.de/tools/checksec.html>`_
- RELocation Read-Only (RELRO)
Hardening der Datenabschnitte einer ausführbaren Datei. Beide Voll- und Teil-RELRO-Modi werden von gcc unterstützt. Für QEMU ist RELRO Ihre beste Wahl. Dadurch wird die globale Offset-Tabelle schreibgeschützt und platziert verschiedene interne Datenabschnitte vor dem Programmdatenabschnitt in der resultierenden ausführbaren Datei.
- Stack canaries
Platziert Werte auf dem Stapel und überprüft ihre Anwesenheit, um Pufferüberlaufangriffe zu verhindern.
- Never eXecute (NX)
Auch bekannt als Data Execution Prevention (DEP), stellt sicher, dass Datenabschnitte der ausführbaren Datei nicht ausgeführt werden können.
- Position Independent Executable (PIE)
Erzeugt eine standunabhängige ausführbare Datei, die für ASLR notwendig ist.
- Address Space Layout Randomization (ASLR)
Dadurch wird sichergestellt, dass die Platzierung von Code- und Datenregionen randomisiert wird. Aktiviert durch den Kernel (alle modernen Linux-Kernel unterstützen ASLR), wenn die ausführbare Datei mit PIE erstellt wird.
Bei der Kompilierung von QEMU werden folgende Compiler-Optionen für GCC empfohlen:
CFLAGS="-arch x86_64 -fstack-protector-all -Wstack-protector \
--param ssp-buffer-size=4 -pie -fPIE -ftrapv -D_FORTIFY_SOURCE=2 -O2 \
-Wl,-z,relro,-z,now"
Wir empfehlen, Ihre QEMU ausführbare Datei zu testen, nachdem sie kompiliert wurde, um sicherzustellen, dass das Compiler-Hardening ordnungsgemäß funktioniert.
Die meisten Cloud-Implementierungen werden keine Software wie QEMU von Hand erstellen. Es ist besser, die Pakete zu verwenden, um sicherzustellen, dass der Prozess wiederholbar ist und um sicherzustellen, dass das Endergebnis in der ganzen Cloud leicht eingesetzt werden kann. Die nachfolgenden Referenzen geben einige zusätzliche Details zur Anwendung von Compiler-Härtungsoptionen auf bestehende Pakete.
- DEB-Pakete:
- RPM-Pakete:
„So erstellen Sie ein RPM-Paket <http://fedoraproject.org/wiki/How_to_create_an_RPM_package>`_
Secure Encrypted Virtualization¶
Secure Encrypted Virtualization (SEV) is a technology from AMD which enables the memory for a VM to be encrypted with a key unique to the VM. SEV is available in the Train release as a technical preview with KVM guests on certain AMD-based machines for the purpose of evaluating the technology.
The KVM hypervisor section of the nova configuration guide contains information needed to configure the machine and hypervisor, and lists several limitations of SEV.
SEV provides protection for data in the memory used by the running VM.
However, while the first phase of SEV integration with OpenStack enables
encrypted memory for VMs, importantly it does not provide the
LAUNCH_MEASURE or LAUNCH_SECRET capabilities which are available with
the SEV firmware. This means that data used by an SEV-protected VM may be
subject to attacks from a motivated adversary who has control of the
hypervisor. For example, a rogue administrator on the hypervisor machine could
provide a VM image for tenants with a backdoor and spyware capable of stealing
secrets, or replace the VNC server process to snoop data sent to or from the
VM console including passwords which unlock full disk encryption solutions.
To reduce the chances for a rogue administrator to gain unauthorized access to data, the following security practices should accompany the use of SEV:
A full disk encryption solution should be used by the VM.
A bootloader password should be used on the VM.
In addition, standard security best practices should be used with the VM including the following:
The VM should be well maintained, including regular security scanning and patching to ensure a continuously strong security posture for the VM.
Connections to the VM should use encrypted and authenticated protocols such as HTTPS and SSH.
Additional security tools and processes should be considered and used for the VM appropriate to the level of sensitivity of the data.
Obligatorische Zugriffskontrollen¶
Compiler-Hardening macht es schwieriger, den QEMU-Prozess anzugreifen. Allerdings, wenn ein Angreifer erfolgreich ist, wollen Sie die Auswirkungen des Angriffs begrenzen. Obligatorische Zugriffskontrollen führen dies durch die Beschränkung der Privilegien auf den QEMU-Prozess nur auf das, was benötigt wird. Dies kann durch die Verwendung von sVirt, SELinux oder AppArmor erreicht werden. Bei der Verwendung von sVirt ist SELinux so konfiguriert, dass jeder QEMU-Prozess unter einem separaten Sicherheitskontext ausgeführt wird. AppArmor kann so konfiguriert werden, dass es eine ähnliche Funktionalität bietet. Weitere Informationen über sVirt und Instanzisolation finden Sie im folgenden Abschnitt sVirt: SELinux und Virtualisierung.
Für viele OpenStack-Dienste stehen spezifische SELinux-Richtlinien zur Verfügung. CentOS-Benutzer können diese Richtlinien durch Installieren des Selinux-Policy-Quellpakets überprüfen. Die aktuellsten Richtlinien erscheinen in Fedora’s selinux-policy Repository. Der rawhide-contrib-Zweig hat Dateien, die in` .te``enden, wie cinder.te`, die auf SELinux-Systemen verwendet werden können.
AppArmor-Profile für OpenStack-Dienste existieren derzeit nicht, aber das OpenStack-Ansible-Projekt verarbeitet dies durch AppArmor-Profile für jeden Container, der einen OpenStack-Dienst ausführt.
sVirt: SELinux und Virtualisierung¶
Mit einzigartiger Kernel-Level-Architektur und NSA entwickelte Sicherheitsmechanismen, bietet KVM fundamentale Isolationstechnologien für Multi-Tenants. Mit entwicklungsorientierten Ursprüngen aus dem Jahr 2002 ist die Secure Virtualization (sVirt)-Technologie die Anwendung von SELinux gegen die moderne Virtualisierung. SELinux, das entworfen wurde, um eine Trennungssteuerung basierend auf Etiketten anzuwenden, wurde erweitert, um eine Isolierung zwischen virtuellen Maschinenprozessen, Geräten, Datendateien und Systemprozessen, die in ihrem Namen handeln, bereitzustellen.
OpenStacks sVirt-Implementierung strebt an, Hypervisor-Hosts und virtuelle Maschinen vor zwei primären Bedrohungsvektoren zu schützen:
- Hypervisor-Bedrohungen
Eine kompromittierte Anwendung, die innerhalb einer virtuellen Maschine läuft, greift den Hypervisor an, um auf zugrunde liegende Ressourcen zuzugreifen. Wenn zum Beispiel eine virtuelle Maschine auf das Hypervisor-Betriebssystem, physikalische Geräte oder andere Anwendungen zugreifen kann. Dieser Bedrohungsvektor stellt ein beträchtliches Risiko dar, da ein Kompromiss auf einem Hypervisor die physikalische Hardware infizieren und andere virtuelle Maschinen und Netzwerksegmente aussetzen kann.
- Virtual Machine (Multi-Tenant) Bedrohungen
Eine kompromittierte Anwendung, die innerhalb einer VM läuft, greift den Hypervisor an, um auf eine andere virtuelle Maschine und ihre Ressourcen zuzugreifen oder sie zu steuern. Dies ist ein Bedrohungsvektor, der für die Virtualisierung einzigartig ist und ein beträchtliches Risiko darstellt, da eine Vielzahl von virtuellen Maschinen-Dateibildern aufgrund einer Anfälligkeit in einer einzigen Anwendung beeinträchtigt werden könnte. Dieser virtuelle Netzwerkangriff ist ein wichtiges Anliegen, da die administrativen Techniken zum Schutz von realen Netzwerken nicht direkt auf die virtuelle Umgebung zutreffen.
Jede KVM-basierte virtuelle Maschine ist ein Prozess, der von SELinux gekennzeichnet ist und eine Sicherheitsgrenze um jede virtuelle Maschine effektiv etabliert. Diese Sicherheitsgrenze wird vom Linux-Kernel überwacht und erzwungen, wodurch der Zugriff der virtuellen Maschine auf Ressourcen außerhalb der Grenze, wie z. B. Host-Computer-Datendateien oder andere VMs, eingeschränkt wird.
sVirt-Isolation wird unabhängig vom Gastbetriebssystem, das innerhalb der virtuellen Maschine läuft, bereitgestellt. Linux oder Windows VMs können verwendet werden. Darüber hinaus bieten viele Linux-Distributionen SELinux innerhalb des Betriebssystems, so dass die virtuelle Maschine interne virtuelle Ressourcen vor Bedrohungen schützen kann.
Etiketten und Kategorien¶
KVM-basierte virtuelle Maschineninstanzen sind mit ihrem eigenen SELinux- Datentyp gekennzeichnet, der als ``svirt_image_t``bekannt ist. Kernel- Level-Schutz verhindert unautorisierte Systemprozesse wie Malware, um die virtuellen Maschinen-Image-Dateien auf der Festplatte zu manipulieren. Wenn virtuelle Maschinen ausgeschaltet sind, werden die Abbilder als `` svirt_image_t``wie unten gezeigt gespeichert:
system_u:object_r:svirt_image_t:SystemLow image1
system_u:object_r:svirt_image_t:SystemLow image2
system_u:object_r:svirt_image_t:SystemLow image3
system_u:object_r:svirt_image_t:SystemLow image4
Das ``svirt_image_t``Label identifiziert eindeutig Abbilddateien auf der Festplatte, so dass die SELinux-Richtlinie den Zugriff beschränken kann. Wenn ein KVM-basiertes Compute-Abbild eingeschaltet wird, hängt sVirt dem Abbild eine zufällige numerische Kennung an. sVirt ist in der Lage, numerische
Dieses Beispiel zeigt die sVirt Kategorie Kennung:
system_u:object_r:svirt_image_t:s0:c87,c520 image1
system_u:object_r:svirt_image_t:s0:419,c172 image2
SELinux Benutzer und Rollen¶
SELinux verwaltet Benutzerrollen. Diese können durch das -Z-Flag
angezeigt werden, oder mit dem Befehl semanage. Auf dem
Hypervisor sollten nur Administratoren in der Lage sein, auf das System
zuzugreifen und sollten einen geeigneten Kontext sowohl für die
administrativen Benutzer als auch für alle anderen Benutzer haben, die sich
auf dem System befinden. Weitere Informationen finden Sie in der `SELinux
Benutzerdokumentation <http://selinuxproject.org/page/BasicConcepts#Users>
Booleans¶
Um den administrativen Aufwand für die Verwaltung von SELinux zu erleichtern, nutzen viele Enterprise-Linux-Plattformen SELinux Booleans, um schnell die Sicherheitsposition von sVirt zu ändern.
Red Hat Enterprise Linux-basierte KVM-Implementierungen nutzen die folgenden sVirt booleans:
svirt SELinux Boolean |
Beschreibung |
|---|---|
virt_use_common |
Erlauben Sie virt, serielle oder parallele Kommunikationsschnittstellen zu verwenden. |
virt_use_fusefs |
Erlaube virt, FUSE-Dateien zu lesen. |
virt_use_nfs |
Erlaube virt, NFS-Dateien zu verwalten. |
virt_use_samba |
Erlaube virt, CIFS-Dateien zu verwalten. |
virt_use_sanlock |
Erlaube beschränkten virtuellen Gästen, mit dem Sanlock zu interagieren. |
virt_use_sysfs |
Erlaube virt, die Gerätekonfiguration (PCI) zu verwalten. |
virt_use_usb |
Erlaube virt, USB-Geräte zu verwenden. |
virt_use_xserver |
Erlaube virtuelle Maschine, mit dem X-Window-System zu interagieren. |
