Kap 10 High End BS
This commit is contained in:
		
							parent
							
								
									03d4254912
								
							
						
					
					
						commit
						d707d43e40
					
				| @ -94,6 +94,12 @@ author: Robert Jeutter | ||||
|     - [Memory Mapped E/A](#memory-mapped-ea) | ||||
|   - [Software Prinzipien](#software-prinzipien) | ||||
|   - [Zusammenfassung](#zusammenfassung-4) | ||||
| - [High-End-Betriebssysteme](#high-end-betriebssysteme) | ||||
|   - [Was sind High-End- Betriebssysteme?](#was-sind-high-end--betriebssysteme) | ||||
|   - [Sicherheit](#sicherheit) | ||||
|     - [Ein Beispiel: SELinux](#ein-beispiel-selinux) | ||||
|   - [Robustheit](#robustheit) | ||||
|   - [Abschließend](#abschließend) | ||||
| 
 | ||||
| # Einführung | ||||
| worauf es ankommt: | ||||
| @ -2299,3 +2305,93 @@ Software-Prinzipien | ||||
|   - Auftragsmanagement | ||||
|   - ISRs | ||||
| 
 | ||||
| # High-End-Betriebssysteme | ||||
| ## Was sind High-End- Betriebssysteme? | ||||
| In-etwa-Übersetzung: „Fortgeschrittene“ Betriebssysteme (engl. „Advanced Operating Systems“) | ||||
| 
 | ||||
| Es geht um: | ||||
| - „Einbau“ nichtfunktionaler Eigenschaften | ||||
| - neue Konzepte für die Architektur von Betriebssystemen | ||||
| - neue Abstraktionen innerhalb von Betriebssystemen | ||||
| - ... | ||||
| 
 | ||||
| Wir greifen 2 nichtfunktionale Eigenschaften von Betriebssystemen heraus, die insbesondere damit zu tun haben, dass kein (Betriebs)System vollständig fehlerfrei ist! und eine wichtige Notwendigkeit besteht in der **Reduktion operationaler Risiken Verantwortbarkeit** | ||||
| 
 | ||||
| ## Sicherheit | ||||
| Das Problem: Paradigmatische Grundlagen heutiger Mainstream-Betriebssysteme stammen aus den 60er Jahren des letzten Jahrtausends (Prozesse, Dateien, Kommunikation, ...) | ||||
| 
 | ||||
| Die Folge: Für viele kritische Anwendungsgebiete | ||||
| - unzulängliche Paradigmen | ||||
| - schwache Implementierungen | ||||
| - unzureichende Sicherheit (engl. Security – nicht Safety!!) z.B. gegen Hacker, Spionage, Sabotage ... | ||||
|    | ||||
| High End: Paradigmenwechsel | ||||
| 
 | ||||
| ### Ein Beispiel: SELinux | ||||
| Ziel: Security Enhanced Linux | ||||
| 1. state-of-the-art Betriebssystem | ||||
| 2. state-of-the-art Sicherheitsparadigmen | ||||
| 
 | ||||
| Idee: durch Sicherheitspolitik gesteuertes Betriebssystem | ||||
| 
 | ||||
| Technischer Ansatz (z.B.) SELinux = Linux + Sicherheitspolitiken | ||||
| 
 | ||||
| Sicherheitspolitiken in SELinux | ||||
| - neue Betriebssystem-Abstraktion (die erste seit 50 Jahren) | ||||
| - absolute Kontrolle über kritische Funktionen des Betriebssystems | ||||
| - spezifiziert durch Regelmenge | ||||
| - implementiert durch die SELinux-Sicherheitsarchitektur | ||||
| 
 | ||||
| SELinux-Sicherheitsarchitektur | ||||
| - Security Server (strategische Komponente): Laufzeitumgebung für Sicherheitspolitik in Schutzdomäne des BS-Kerns | ||||
| - Interzeptoren (Politikdurchsetzung): vollständige Kontrolle | ||||
|    | ||||
| Spezifikation einer Sicherheitspolitik | ||||
| - Sicherheitspolitik: Regelmenge der Art | ||||
|   ``` | ||||
|     allow <user_dom> | ||||
|     <apps_dom>: <mailer> | ||||
|     allow <execute> | ||||
|     <auth_dom> <auth_dom>: <passwd> <write> | ||||
|   ``` | ||||
| - kritisch | ||||
|   - Korrektheit (100.000 Regeln ...) | ||||
|   - Vollständigkeit | ||||
|   - Widerspruchsfreiheit | ||||
| - Security Engineering | ||||
|   - Politikspezifikation | ||||
|   - Politikanalyse | ||||
|   - Sicherheitsarchitekturen | ||||
| 
 | ||||
| ## Robustheit | ||||
| Ziel: Tolerierung unvorhergesehener Fehler und Ausfälle | ||||
| 
 | ||||
| Auch hier ein Beispiel: Architekturprinzipien | ||||
| 1. monolithische Architektur | ||||
|   - BS-Komponenten zusammengefasst zu | ||||
|     - einem Programmsystem | ||||
|     - in einem Adressraum | ||||
|   - Kommunikation untereinander mittels Prozeduraufrufen | ||||
|   - Fehlerausbreitung: innerhalb des (großen) BS-Adressraums | ||||
| 2. Mikrokernarchitektur | ||||
|   - BS-Komponenten bilden | ||||
|     - separate Funktionseinheiten | ||||
|     - mit individuellen Adressräumen | ||||
|   - Kommunikation: mittels Prozedurfernaufrufen | ||||
|   - Fehlerausbreitung: gestoppt an Adressraumgrenze(n) | ||||
| 
 | ||||
| Folgen | ||||
| 1. Korrektheit | ||||
|     - Fehlerausbreitung | ||||
|     - Aussagekraft formaler Verifikation von BS-Komponenten | ||||
| 2. Robustheit | ||||
|     - Fehlerisolation | ||||
|     - Fehlerbehebung (vgl. Micro-Reboot) | ||||
| 
 | ||||
| ## Abschließend | ||||
| Risikoszenarien und High-End Betriebssysteme | ||||
| - IT-Sicherheit & Security Engineering | ||||
|   - Design von Sicherheitseigenschaften und Architekturen | ||||
| - AOS | ||||
|   - (z.B. Robustheit) | ||||
|   - Konzepte, Architekturen, Algorithmen | ||||
		Loading…
	
		Reference in New Issue
	
	Block a user