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