Sicherheit gekürzt
This commit is contained in:
parent
ccb8f75128
commit
9f091c7d9c
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
BIN
Advanced Operating Systems - Cheatsheet.pdf
(Stored with Git LFS)
Binary file not shown.
@ -1328,18 +1328,9 @@
|
||||
|
||||
\pagebreak
|
||||
\section{Sicherheit}
|
||||
Terminologie
|
||||
\begin{description*}
|
||||
\item[Security] IT-Sicherheit, Informationssicherheit
|
||||
\begin{itemize*}
|
||||
\item Ziel: Schutz \textbf{des} Rechnersystems
|
||||
\item Systemsicherheit, hier besprochen
|
||||
\end{itemize*}
|
||||
\item[Safety] Funktionale Sicherheit, Betriebssicherheit
|
||||
\begin{itemize*}
|
||||
\item Ziel: Schutz \textbf{vor} einem Rechnersystem
|
||||
\item an dieser Stelle nicht besprochen
|
||||
\end{itemize*}
|
||||
\item[Security] IT/Informations-Sicherheit, Schutz \textbf{des} Rechnersystems
|
||||
\item[Safety] Funktionale/Betriebs-Sicherheit, Schutz \textbf{vor} Rechnersystem
|
||||
\end{description*}
|
||||
%Eine (unvollständige) Taxonomie: \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-sicherheit-taxonomie.png}
|
||||
|
||||
@ -1369,8 +1360,8 @@
|
||||
\end{itemize*}
|
||||
\item (Wirtschafts-) Spionage und Diebstahl
|
||||
\begin{itemize*}
|
||||
\item Verlust der Kontrolle über kritisches Wissen ($\rightarrow$ Risikotechnologien)
|
||||
\item immense wirtschaftliche Schäden, z.B. Diebstahl von industriellem Know-How
|
||||
\item Verlust der Kontrolle über kritisches Wissen %($\rightarrow$ Risikotechnologien)
|
||||
\item immense wirtschaftliche Schäden%, z.B. Diebstahl von industriellem Know-How
|
||||
\end{itemize*}
|
||||
\item Betrug, persönliche Bereicherung (wirtschaftliche Schäden)
|
||||
\item Sabotage, Erpressung
|
||||
@ -1390,8 +1381,8 @@
|
||||
\begin{itemize*}
|
||||
\item (teil-) automatisierte Angriffe
|
||||
\item Trojanische Pferde: scheinbar nützliche Software
|
||||
\item Viren, Würmer: Funktionalität zur eigenen Vervielfältigung und/oder Modifikation
|
||||
\item Logische Bomben: trojanischen Pferde, deren Aktivierung an System- oder Datumsereignisse gebunden
|
||||
\item Viren, Würmer: Funktionalität zur eigenen Vervielfältigung %und/oder Modifikation
|
||||
\item Logische Bomben: trojanischen Pferde mit Aktivierung %an System- oder Datumsereignisse gebunden
|
||||
\item Root Kits
|
||||
\end{itemize*}
|
||||
\item Bots und Botnets
|
||||
@ -1403,16 +1394,7 @@
|
||||
|
||||
\subsubsection{Professionelle Malware: Root Kit}
|
||||
\begin{itemize*}
|
||||
\item Programm-Paket, das unbemerkt Betriebssystem modifiziert, um Administratorrechte zu erlangen
|
||||
\item Voraussetzung: eine einzige Schwachstelle...
|
||||
\item ermöglichen Zugriff auf alle Funktionen und Dienste eines Betriebssystems
|
||||
\item Angreifer erlangt vollständige Kontrolle des Systems und kann
|
||||
\begin{itemize*}
|
||||
\item Dateien (Programme) hinzufügen bzw. ändern
|
||||
\item Prozesse überwachen
|
||||
\item über die Netzverbindungen senden und empfangen
|
||||
\item Hintertüren für zukünftiger Angriffe platzieren
|
||||
\end{itemize*}
|
||||
\item Angreifer erlangt vollständige Kontrolle des Systems
|
||||
\item Ziele eines Rootkits
|
||||
\begin{itemize*}
|
||||
\item seine Existenz verbergen
|
||||
@ -1431,7 +1413,7 @@
|
||||
\subsubsection{Schwachstellen}
|
||||
\begin{enumerate*}
|
||||
\item Passwort (erraten, zu einfach, Brute-Force, Abfangen)
|
||||
\item Programmierfehler (Speicherfehler in Anwenderprogrammen/Gerätemanagern/Betriebssystem
|
||||
\item Programmierfehler (Speicherfehler) % in Anwenderprogrammen/Gerätemanagern/Betriebssystem
|
||||
\item Mangelhafte Robustheit
|
||||
\begin{itemize*}
|
||||
\item keine Korrektur fehlerhafter Eingaben
|
||||
@ -1440,17 +1422,16 @@
|
||||
\item Nichttechnische Schwachstellen
|
||||
\begin{itemize*}
|
||||
\item physisch, organisatorisch, infrastrukturell
|
||||
\item menschlich ( $\rightarrow$ Erpressung, socialengineering )
|
||||
\item menschlich ($\rightarrow$ Erpressung, social engineering)
|
||||
\end{itemize*}
|
||||
\end{enumerate*}
|
||||
|
||||
\subsubsection{Zwischenfazit}
|
||||
\begin{itemize*}
|
||||
\item Schwachstellen sind unvermeidbar
|
||||
\item Bedrohungen sind unkontrollierbar
|
||||
\item ... und nehmen tendeziell zu!
|
||||
\item Bedrohungen sind unkontrollierbar und nehmen tendeziell zu
|
||||
\item führt zu operationellen Risiken beim Betrieb eines IT-Systems
|
||||
\item[$\rightarrow$] Aufgabe der BS-Sicherheit: Auswirkungen operationeller Risiken reduzieren
|
||||
\item[$\rightarrow$] BS-Sicherheit: Auswirkungen operationeller Risiken reduzieren
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Sicherheitspolitiken}
|
||||
@ -1461,55 +1442,50 @@
|
||||
\begin{description}
|
||||
\item[Sicherheitsziele] Welche Sicherheitsanforderungen muss BS erfüllen?
|
||||
\item[Sicherheitspolitik] Durch welche Strategien soll es diese erfüllen?
|
||||
\begin{itemize*}
|
||||
\item Menge von Regeln, zum Erreichen eines Sicherheitsziels
|
||||
\end{itemize*}
|
||||
\item[Sicherheitsmechanismen] Wie implementiert BS Sicherheitspolitik?
|
||||
\begin{itemize*}
|
||||
\item Verifikation ihrer Korrektheit
|
||||
\item Spezifikation ihrer Implementierung
|
||||
\end{itemize*}
|
||||
\item[Sicherheitsarchitektur] Wo implementiert BS S.-mechanismen?
|
||||
\end{description}
|
||||
|
||||
\subsubsection{Sicherheitspolitiken und -modelle}
|
||||
Kritisch für korrekten Entwurf, Spezifikation, Implementierung
|
||||
\begin{itemize*}
|
||||
\item Sicherheitspolitik (Policy): Menge von Regeln, zum Erreichen eines Sicherheitsziels
|
||||
\item Sicherheitsmodell: formale Darstellung zur
|
||||
\begin{itemize*}
|
||||
\item Verifikation ihrer Korrektheit
|
||||
\item Spezifikation ihrer Implementierung
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Zugriffssteuerungspolitiken}
|
||||
\begin{description*}
|
||||
\item[Zugriffssteuerung] (access control) Steuerung, welcher Nutzer oder Prozess mittels welcher Operationen auf welche BS-Ressourcen zugreifen darf
|
||||
\item[Zugriffssteuerung] Steuerung, welcher Nutzer/Prozess mittels welcher Operationen auf welche BS-Ressourcen zugreifen darf
|
||||
\item[Zugriffssteuerungspolitik] konkrete Regeln, welche die Zugriffssteuerung in einem BS beschreiben
|
||||
\item[IBAC] (Identity-based AC) Politik spezifiziert, welcher Nutzer an welchen Ressourcen bestimmte Rechte hat
|
||||
\begin{itemize*}
|
||||
\item Bsp.: ,,Nutzer Anna darf Brief.docx lesen''
|
||||
\end{itemize*}
|
||||
\item[TE] (Type-Enforcement) Politik spezifiziert Rechte durch zusätzliche Abstraktion (Typen): welcher Nutzertyp an welchem Ressourcentyp bestimmte Rechte hat
|
||||
\item[TE] (Type-Enforcement) Politik spezifiziert Rechte durch zusätzliche Abstraktion (Typen) %welcher Nutzertyp an welchem Ressourcentyp bestimmte Rechte hat
|
||||
\begin{itemize*}
|
||||
\item Bsp.: ,,Nutzer vom Typ Administrator darf...''
|
||||
\end{itemize*}
|
||||
\item[MLS] (Multi-Level Security) Politik spezifiziert Rechte, indem aus Nutzern und Ressourcen hierarchische Klassen (Ebenen, ,,Levels'') gleicher Kritikalität im Hinblick auf Sicherheitsziele gebildet werden
|
||||
\item[MLS] (Multi-Level Security) Politik spezifiziert Rechte, indem aus Nutzern und Ressourcen hierarchische Klassen gleicher Kritikalität im Hinblick auf Sicherheitsziele gebildet werden
|
||||
\begin{itemize*}
|
||||
\item Bsp.: ,,Nutzer der Klasse nicht vertrauenswürdig...''
|
||||
\end{itemize*}
|
||||
\item[DAC] (Discretionary AC): Aktionen der Nutzer setzen die Sicherheitspolitik durch. Typisch: Begriff des Eigentümers von BS-Ressourcen
|
||||
\item[DAC] (Discretionary AC): Aktionen der Nutzer setzen die Sicherheitspolitik durch % Typisch: Begriff des Eigentümers von BS-Ressourcen
|
||||
\begin{itemize*}
|
||||
\item Bsp.: ,,Der Eigentümer einer Datei ändert...''
|
||||
\end{itemize*}
|
||||
\item[MAC] (Mandatory AC, obligatorische Zugriffssteuerung) Keine Beteiligung der Nutzer an der Durchsetzung einer (zentral administrierten) Sicherheitspolitik
|
||||
\item[MAC] (Mandatory AC) Keine Beteiligung der Nutzer an der Durchsetzung einer (zentral administrierten) Sicherheitspolitik
|
||||
\begin{itemize*}
|
||||
\item Bsp.: ,,Anhand des Dateisystempfads bestimmt BS...''
|
||||
\end{itemize*}
|
||||
\end{description*}
|
||||
|
||||
\subsubsection{Traditionell: DAC, IBAC}
|
||||
Auszug aus der Unix-Sicherheitspolitik:
|
||||
\begin{itemize*}
|
||||
\item es gibt Subjekte (Nutzer/Prozesse) und Objekte (Dateien,\dots)
|
||||
\item jedes Objekt hat einen Eigentümer
|
||||
\item Eigentümer legen Zugriffsrechte an Objekten fest ($\rightarrow$ DAC)
|
||||
\item es gibt drei Zugriffsrechte: read, write, execute
|
||||
\item je Objekt gibt es drei Klassen von Subjekten, mit individuellen Zugriffsrechten: Eigentümer, Gruppe, Rest
|
||||
\item je Objekt gibt es drei Klassen von Subjekten: Eigentümer, Gruppe, Rest
|
||||
\end{itemize*}
|
||||
|
||||
In der Praxis
|
||||
@ -1522,16 +1498,15 @@
|
||||
\subsubsection{Modellierung: Zugriffsmatrix}
|
||||
\begin{itemize*}
|
||||
\item Access Control Matrix (acm): Momentaufnahme der globalen Rechteverteilung zu einem definierten Zeitpunkt t
|
||||
\item Korrektheitskriterium: Wie kann sich dies nach t möglicherweise ändern...?
|
||||
\item Korrektheitskriterium: Wie kann sich dies möglicherweise ändern?
|
||||
\item Rechteausbreitung (privilege escalation): verursacht z.B. durch Nutzeraktion ($\rightarrow$ DAC)
|
||||
\item Sicherheitseigenschaft: HRU Safety $\rightarrow$ Systemsicherheit
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Modern: MAC, MLS}
|
||||
Sicherheitspolitik der Windows UAC (user account control)
|
||||
\begin{itemize*}
|
||||
\item es gibt Subjekte (Prozesse) und Objekte (Dateisystemknoten)
|
||||
\item jedem Subjekt ist eine Integritätsklasse zugewiesen:
|
||||
\item jedem Subjekt ist eine Integritätsklasse zugewiesen
|
||||
\begin{description*}
|
||||
\item[Low] nicht vertrauenswürdig
|
||||
\item[Medium] reguläre Nutzerprozesse, die Nutzerdaten manipulieren
|
||||
@ -1539,12 +1514,11 @@
|
||||
\item[System] (Hintergrund-) Prozesse, die ausschließlich Betriebssystemdienste auf Anwenderebene implementieren
|
||||
\end{description*}
|
||||
\item jedem Objekt ist analog eine dieser Integritätsklassen zugewiesen
|
||||
\item sämtliche DAC-Zugriffsrechte müssen mit einer Hierarchie der Integritätsklassen konsistent sein ( $\rightarrow$ MAC)
|
||||
\item sämtliche DAC-Zugriffsrechte müssen mit einer Hierarchie der Integritätsklassen konsistent sein ($\rightarrow$ MAC)
|
||||
\item Nutzer können Konsistenzanforderung selektiv außer Kraft setzen ($\rightarrow$ DAC)
|
||||
\end{itemize*}
|
||||
|
||||
MAC-Modellierung: Klassenhierarchie
|
||||
|
||||
Beispiel Relation: $\leq=\{(High,Medium), (High,Low), (Medium,Low), (High,High), (Low,Low)\}$
|
||||
\begin{itemize*}
|
||||
\item repräsentiert Kritikalität hinsichtlich der Integrität
|
||||
@ -1576,9 +1550,9 @@
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Traditionell: ACLs, SUID}
|
||||
Autorisierungsinformationen:
|
||||
Autorisierungsinformationen
|
||||
\begin{itemize*}
|
||||
\item müssen Subjekte (Nutzer) bzw. Objekte (Dateien, Sockets ...) mit Rechten assoziieren $\rightarrow$ Implementierung der Zugriffsmatrix (acm), diese ist:
|
||||
\item müssen Subjekte (Nutzer) bzw. Objekte (Dateien, Sockets ...) mit Rechten assoziieren $\rightarrow$ Implementierung der Zugriffsmatrix (acm)
|
||||
\begin{itemize*}
|
||||
\item groß ($\rightarrow$ Dateianzahl auf Fileserver)
|
||||
\item dünn besetzt
|
||||
@ -1601,14 +1575,8 @@
|
||||
Rest (o) & ja & nein & ja
|
||||
\end{tabular}
|
||||
\begin{itemize*}
|
||||
\item 3-elementige Liste, 3-elementige Rechtemenge
|
||||
\item[$\rightarrow$] 9 Bits
|
||||
\item 3-elementige Liste, 3-elementige Rechtemenge $\rightarrow$ 9 Bits
|
||||
\item Implementierung kodiert in 16-Bit-Wort: 1 1 1 1 0 1 1 0 1
|
||||
\end{itemize*}
|
||||
|
||||
\subparagraph{Autorisierungsmechanismen: ACL-Auswertung}
|
||||
Subjekte = Nutzermenge besteht aus Anzahl registrierter Nutzer
|
||||
\begin{itemize*}
|
||||
\item jeder hat eindeutige UID (userID), z.B. integer- Zahl
|
||||
\item Dateien \& Prozesse mit UID des Eigentümers versehen
|
||||
\begin{itemize*}
|
||||
@ -1616,41 +1584,24 @@
|
||||
\item bei Prozessen: Teil des PCB
|
||||
\item standardmäßiger Eigentümer: der Ressource erzeugt hat
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Nutzergruppen (groups)
|
||||
\begin{itemize*}
|
||||
\item jeder Nutzer durch Eintrag in Systemdatei (/etc/group) einer/mehreren Gruppen zugeordnet ($\rightarrow$ ACL: g Rechte)
|
||||
\end{itemize*}
|
||||
|
||||
Superuser oder root... hat grundsätzlich uneingeschränkte Rechte.
|
||||
\begin{itemize*}
|
||||
\item UID = 0
|
||||
\item darf alle Dateien im System lesen, schreiben, ausführen
|
||||
\item unabhängig von ACL
|
||||
\item jeder Nutzer durch Eintrag in Systemdatei (/etc/group) einer/mehreren Gruppen zugeordnet ($\rightarrow$ ACL)
|
||||
\item Superuser oder root... hat grundsätzlich uneingeschränkte Rechte
|
||||
\end{itemize*}
|
||||
|
||||
\subparagraph{ACL-Implementierung}
|
||||
Nutzerrechte $\rightarrow$ Prozessrechte
|
||||
|
||||
Durchsetzung: basiert auf Prozessrechten
|
||||
\begin{itemize*}
|
||||
\item Annahme: Prozesse laufen mit UID des Nutzers, der sie gestartet hat und repräsentieren Nutzerberechtigungen
|
||||
\item technisch: Nutzer beauftragt anderen Prozess, sich zu dublizieren (fork()) und gewünschte Programm auszuführen (exec*())
|
||||
\item Vererbungsprinzip %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-acl-vererbungsprinzip.png}
|
||||
%\item Vererbungsprinzip %\includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-acl-vererbungsprinzip.png}
|
||||
\end{itemize*}
|
||||
|
||||
\subparagraph{Autorisierungsmechanismen: Set-UID}
|
||||
|
||||
konsequente Rechtevererbung
|
||||
\begin{itemize*}
|
||||
\item Nutzer können im Rahmen der DAC-Politik ACLs manipulieren
|
||||
\item Nutzer können (i.A.) jedoch keine Prozess-UIDs manipulieren
|
||||
\item $\rightarrow$ und genau so sollte es gem. Unix-Sicherheitspolitik auch sein!
|
||||
\end{itemize*}
|
||||
|
||||
Hintergrund
|
||||
\begin{itemize*}
|
||||
\item[$\rightarrow$] und genau so sollte es gem. Unix-Sicherheitspolitik auch sein
|
||||
\item Unix-Philosophie ,, everything is a file '': BS-Ressourcen wie Sockets, E/A-Gerätehandler als Datei repräsentiert $\rightarrow$ identische Schutzmechanismen zum regulären Dateisystem
|
||||
\item somit: Autorisierungsmechanismen zur Begrenzung des Zugriffs auf solche Geräte nutzbar
|
||||
\begin{itemize*}
|
||||
@ -1673,14 +1624,6 @@
|
||||
\item[$\rightarrow$] Nutzerprozesse können Systemprogramme ohne permanente root-Rechte ausführen
|
||||
\end{itemize*}
|
||||
|
||||
Weiteres Beispiel: passwd
|
||||
\begin{itemize*}
|
||||
\item ermöglicht Nutzern Ändern des (eigenen) Anmeldepassworts
|
||||
\item Schreibzugriff auf /etc/shadow (Password-Hashes) erforderlich
|
||||
\item Lösung: `-rws rws r-x 1 root root 1 2005-01-20 10:00 passwd\$
|
||||
\item passwd-Programm wird mit root-Rechten ausgeführt und passwd schreibt nur eigenen Passwort-Hash
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Modern: SELinux}
|
||||
\begin{itemize*}
|
||||
\item 2000er: sicherheitsfokussiertes Betriebssystemprojekt für NSA
|
||||
@ -1692,11 +1635,7 @@
|
||||
\item zentrale Datenstruktur für Regeln, die erlaubte Zugriffe auf ein SELinux-System definiert
|
||||
\item erlaubt Modifikation und Anpassung an verschiedene Sicherheitsanforderungen $\rightarrow$ NFE Adaptivität ...
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
BS-Komponenten
|
||||
\begin{itemize*}
|
||||
\item Auswertung: Security-Server, implementiert als Linux-Kernelmodul $\rightarrow$ entscheidet über alle Zugriffe auf alle Objekte
|
||||
\item Security-Server, implementiert als Linux-Kernelmodul $\rightarrow$ entscheidet über alle Zugriffe auf alle Objekte
|
||||
\item Durchsetzung der Sicherheitspolitik: LSM Hooks
|
||||
\item Administration: geschrieben in Textform, muss zur Laufzeit in Security Server installiert werden
|
||||
\end{itemize*}
|
||||
@ -1716,19 +1655,17 @@
|
||||
\item Type Enforcement (TE): Typisierung von
|
||||
\begin{itemize*}
|
||||
\item Subjekten: Prozesse
|
||||
\item Objekten der Klassen: Dateien, Sockets, Geräteschnittstellen, ...
|
||||
\item Objekten der Klassen: Dateien, Sockets, Geräte, ...
|
||||
\end{itemize*}
|
||||
\item Rechte delegation durch Retypisierung (vgl. Unix-SUID)
|
||||
%\item \includegraphics[width=\linewidth]{Assets/AdvancedOperatingSystems-selinux-retypisierung.png}
|
||||
\end{itemize*}
|
||||
|
||||
\subparagraph{Autorisierungsinformationen}
|
||||
Security Context: Respräsentiert SELinux-Autorisierungsinformationen für jedes Objekt (Semantik: Prozess bash läuft mit Typ \texttt{shell\_t})
|
||||
Security Context: Respräsentiert SELinux-Autorisierungsinformationen für jedes Objekt %(Semantik: Prozess bash läuft mit Typ \texttt{shell\_t})
|
||||
|
||||
\subparagraph{Autorisierungsregeln}
|
||||
... werden systemweit festgelegt in dessen Sicherheitspolitik ($\rightarrow$ MAC)
|
||||
|
||||
Access Vector Rules
|
||||
... werden systemweit festgelegt in dessen Sicherheitspolitik ($\rightarrow$ MAC): Access Vector Rules
|
||||
\begin{itemize*}
|
||||
\item Autorisierungsregeln basierend auf Subjek-/Objekttypen
|
||||
\item Zugriffe müssen explizit gewährt werden (default-deny)
|
||||
@ -1758,9 +1695,9 @@
|
||||
SELinux: weitere Politiksemantiken
|
||||
\begin{itemize*}
|
||||
\item hier gezeigt: Überblick über TE
|
||||
\item außerdem relevant für SELinux-Politiken (und deren Administration)
|
||||
\item außerdem relevant für SELinux-Politiken %(und deren Administration)
|
||||
\begin{itemize*}
|
||||
\item Einschränkung von erlaubten Typtransitionen (Welches Programm darf mit welchem Typ ausgeführt werden?)
|
||||
\item Einschränkung von erlaubten Typtransitionen %(Welches Programm darf mit welchem Typ ausgeführt werden?)
|
||||
\item weitere Abstraktionsschicht: rollenbasierte Regeln (RBAC)
|
||||
\item[$\rightarrow$] Schutz gegen nicht vertrauenswürdige Nutzer
|
||||
\end{itemize*}
|
||||
@ -1768,33 +1705,26 @@
|
||||
\item[\cmark] obligatorische Durchsetzung ( $\rightarrow$ MAC, zusätzlich zu DAC)
|
||||
\item[O] Softwareentwicklung: Legacy-Linux-Anwendungen ohne Einschränkung
|
||||
\item[\xmark] Politikentwicklung und -administration komplex
|
||||
\item[$\rightarrow$] MAC-Mechanismen ala SELinux sind heutzutage in vielerlei Software bereits zu finden
|
||||
\item[$\rightarrow$] MAC-Mechanismen ala SELinux in vielerlei Software zu finden
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Isolationsmechanismen}
|
||||
\begin{itemize*}
|
||||
\item bekannt: Isolationsmechanismen für robuste Betriebssysteme
|
||||
\begin{itemize*}
|
||||
\item strukturierte Programmierung
|
||||
\item Adressraumisolation
|
||||
\end{itemize*}
|
||||
\item nun: Isolationsmechanismen für sichere Betriebssysteme
|
||||
\begin{itemize*}
|
||||
\item Isolationsmechanismen für sichere Betriebssysteme
|
||||
\item krypto. Hardwareunterstützung: Intel SGX Enclaves
|
||||
\item sprachbasiert:
|
||||
\item sprachbasiert
|
||||
\begin{itemize*}
|
||||
\item streng typisierte Sprachen und \emph{managed code}: Microsoft Singularity
|
||||
\item speichersichere Sprachen (Rust) + Adressraumisolation ($\mu$Kernel): \href{https://www.redox-os.org/}{RedoxOS}
|
||||
\end{itemize*}
|
||||
\item isolierte Laufzeitumgebungen: Virtualisierung
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Intel SGX}
|
||||
\begin{itemize*}
|
||||
\item SGX: Software Guard Extensions
|
||||
\item Ziel: Schutz von sicherheitskritischen Anwendungen durch vollständige, hardwarebasierte Isolation
|
||||
\item $\rightarrow$ strenggenommen kein BS-Mechanismus: Anwendungen müssen dem BS nicht mehr vertrauen
|
||||
\item[$\rightarrow$] strenggenommen kein BS-Mechanismus: Anwendungen müssen dem BS nicht mehr vertrauen
|
||||
\item Annahmen/Voraussetzungen
|
||||
\end{itemize*}
|
||||
\begin{enumerate*}
|
||||
@ -1838,8 +1768,8 @@
|
||||
\item seither in allen Modellen verbaut, jedoch nicht immer aktiviert
|
||||
\item Konzept hardwarebasierter Isolation ...
|
||||
\item[\cmark] liefert erstmals die Möglichkeit zur Durchsetzung von Sicherheitspolitiken auf Anwendungsebene
|
||||
\item[O]setzt Vertrauen in korrekte (und nicht böswillige) Hardwarevoraus
|
||||
\item[O]Dokumentation und Entwicklerunterstützung (im Ausbau ...)
|
||||
\item[O] setzt Vertrauen in korrekte (und nicht böswillige) Hardware voraus
|
||||
\item[O] Dokumentation und Entwicklerunterstützung (im Ausbau ...)
|
||||
\item[\xmark] schützt durch Enclaves einzelne Anwendungen aber nicht System
|
||||
\item[\xmark] steckt in praktischer Eigenschaften (Performanz, Speicher) noch in den Anfängen
|
||||
\end{itemize*}
|
||||
@ -1892,7 +1822,6 @@
|
||||
\item Regeln der Sicherheitspolitik $\rightarrow$ hart codiert, starr
|
||||
\item Sicherheitsattribute, $\rightarrow$ Objekten zugeordnet, modifizierbar
|
||||
\end{itemize*}
|
||||
Man beurteile die Politikimplementierung in dieser Architektur bzgl. Unumgehbarkeit, Manipulationssicherheit und Verifizierbarkeit
|
||||
|
||||
Referenzmonitorimplementierung: Flask
|
||||
\begin{center}
|
||||
@ -1910,7 +1839,7 @@
|
||||
\item Erzeugung neuer Objekte
|
||||
\item Zugriff auf existierende Objekte
|
||||
\end{enumerate*}
|
||||
\item Beispiele: Prozess-Verwaltung, Dateisystem, Networking-System
|
||||
%\item Beispiele: Prozess-Verwaltung, Dateisystem, Networking-System
|
||||
\end{itemize*}
|
||||
|
||||
Dateisystem als Objektmanager
|
||||
@ -1925,7 +1854,7 @@
|
||||
\item für jede Objektklasse: Menge an Permissions definiert, um Zugriffe auf Objekte dieser Klasse zu kontrollieren
|
||||
\item Permissions: abgeleitet aus Dienstleistungen, die Linux-Dateisystem anbietet
|
||||
\item[$\rightarrow$] Objektklassen gruppieren verschiedene Arten von Zugriffsoperationen auf verschiende Arten von Objekten
|
||||
\item z.B. Permissions für alle ,,Datei''-Objektklassen (Auswahl ...)
|
||||
%\item z.B. Permissions für alle ,,Datei''-Objektklassen (Auswahl ...)
|
||||
\end{itemize*}
|
||||
|
||||
\subsubsection{Trusted Computing Base (TCB)}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user