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) |     - [Memory Mapped E/A](#memory-mapped-ea) | ||||||
|   - [Software Prinzipien](#software-prinzipien) |   - [Software Prinzipien](#software-prinzipien) | ||||||
|   - [Zusammenfassung](#zusammenfassung-4) |   - [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 | # Einführung | ||||||
| worauf es ankommt: | worauf es ankommt: | ||||||
| @ -2299,3 +2305,93 @@ Software-Prinzipien | |||||||
|   - Auftragsmanagement |   - Auftragsmanagement | ||||||
|   - ISRs |   - 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