diff --git a/Advanced Operating Systems - Cheatsheet.pdf b/Advanced Operating Systems - Cheatsheet.pdf index 6214dfa..d945971 100644 --- a/Advanced Operating Systems - Cheatsheet.pdf +++ b/Advanced Operating Systems - Cheatsheet.pdf @@ -1,3 +1,3 @@ version https://git-lfs.github.com/spec/v1 -oid sha256:efa48012e554a9dfd6cf7f139909b24f96575d970d3523e2426c6663240b2749 -size 918143 +oid sha256:8625c59cb2f51b3d4cfa31715ca0fa6079ad1dfa99a2318093e1d08c5f776271 +size 914844 diff --git a/Advanced Operating Systems - Cheatsheet.tex b/Advanced Operating Systems - Cheatsheet.tex index f4af504..6d7dedf 100644 --- a/Advanced Operating Systems - Cheatsheet.tex +++ b/Advanced Operating Systems - Cheatsheet.tex @@ -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)}