Systemsicherheit - tu-ilmenau.de · Systemsicherheit, Sommer 2018 © wk - 3 - Begriffe TCB (Trusted...
Transcript of Systemsicherheit - tu-ilmenau.de · Systemsicherheit, Sommer 2018 © wk - 3 - Begriffe TCB (Trusted...
System sicherheit, Som m er 2018 © w k - 1 -
SystemsicherheitKapitel 5: Sicherheitsarchitekturen
Winfried E. KühnhauserSommer 2018
W infried E . Kühnhauser
C SI
Technische U niversität Ilm enau
w w w .tu-ilm enau.de
System sicherheit, Som m er 2018 © w k - 2 -
Roadmap
5 Sicherheitsarchitekturen
Sicherheitsmechanismen
SicherheitspolitikenModellierung und Spezifikation
Sicherheitsarchitekturen
Sicherheitsanforderungen
System sicherheit, Som m er 2018 © w k - 3 -
Begriffe
TCB (Trusted Computing Base)
Die Menge aller Funktionen eines IT-Systems, die zur Herstellung derSicherheitseigenschaften notwendig und hinreichen sind
SicherheitsarchitekturDer Teil einer Systemarchitektur, der die TCB implementiert
SicherheitsmechanismenAlgorithmen und Datenstrukturen zur Implementierung der Funktionen einerTCB
5 Sicherheitsarchitekturen
System sicherheit, Som m er 2018 © w k - 4 -
Sicherheitsarchitekturen kennen wir schon lange …
5 Sicherheitsarchitekturen
System sicherheit, Som m er 2018 © w k - 5 -
ArchitekturkomponentenGebäude, Mauern, Fenster, Türen, Wassergräben, Zugbrücken
ArchitekturAufgaben und Zusammenspiel der Komponenten
Ziel einer SicherheitsarchitekturKonstruktion einer Burganlage so, dass Sicherheitspolitiken durchsetzbar sind
Vorhandensein geeigneter Komponenten/Mechanismen
Unumgehbarkeit
Manipulationssicherheit
→ Architekturprinzipien
5 S icherheitsarchitekturen
System sicherheit, Som m er 2018 © w k - 6 -
MonolithischeBetriebssystem-
architektur
: involvierte Systemkomponenten
Ein (schlimmes) BeispielZugriffssteuerungspolitikimplementierung in Linux
Filesystem Sockets Pipes
Proz.mgmt
open(filename, openmode)
{ ino=namei(filename);switch ino.objecttype of
file:
if (filesystem.checkpermission(ino,openmode))
{ fd=filesystem.open(ino, ...) ...}socket: ...
}
Man beurteile die Politikimplementierung in dieser Architektur bzgl.§ Unumgehbarkeit der Zugriffssteuerung (und deren Nachweisbarkeit)§ Manipulationssicherheit der Politikimplementierung (und deren Nachweisbarkeit)§ Korrektheit der TCB (und deren Nachweisbarkeit)
. . . (ca. 250 Systemaufrufe)
Betriebssystem-Schnittstelle (Application Programmer´s Interface (API))
5 S icherheitsarchitekturen
System sicherheit, Som m er 2018 © w k - 7 -
Problemfelder PDPs (policy decision points)PEPs (policy enforcement points)
sindverstreut über einen weiten Bereich des Betriebssystems→ Problem des Sicherheitsarchitekturdesigns
nicht robust gegenüber Fehlern/Malware◆ innerhalb des gesamten Betriebssystems◆ insbesondere in dynamisch geladenen BS-Modulen
→ Problem der Sicherheitsarchitekturimplementierung
5 Sicherheitsarchitekturen
System sicherheit, Som m er 2018 © w k - 8 -
... und damit nicht genug:
Linux set-user-id-Programmeführen sicherheitssensitive Funktionen aus
nehmen während ihrer Ausführung andere User-Id ein als die des Aufrufershaben damit andere, i.d.R. erweiterte Rechte
insbesondere die der „root“ User-Id
→ sämtliche solche Programme gehören zur TCB (und damit zur Sicherheitsarchitektur!)
z.B. /usr/bin/passwd
/opt/google/chrome/chrome-sandbox (Autor: Google!)/usr/lib/virtualbox/VirtualBox (Autor: Oracle!)
Über die beobachtbaren Konsequenzen braucht man sich somit nicht zu wundern ...
5 S icherheitsarchitekturen
System sicherheit, Som m er 2018 © w k - 9 -
Problem alsoBSe, Middleware-Plattformen und Applikationssysteme sind großlediglich eine kleine Menge ihrer Funktionen gehört logisch zur TCB
→ Sicherheitsarchitekturdesign so, dass die TCB-Funktionen in einem◆ unumgehbaren (Vollständigkeit der Kontrolle)◆ isolierten (Manipulationssicherheit) ◆ vertrauenswürdigen (Korrektheit)
Kern realisiert sind→ Sicherheitsarchitekturimplementierung so, dass diese Eigenschaften
aufrecht erhalten sind
5 S icherheitsarchitekturen
System sicherheit, Som m er 2018 © w k - 10 -
5.1 Architekturprinzipien
Zielvollständigemanipulationssicherenachweisbare
Beherrschung aller sicherheitsrelevanten Operationen in einem IT-System
WegDefinition grundlegender Designprinzipien für Sicherheitsarchitekturen
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 11 -
Die Referenzmonitor-Architekturprinzipien
Es gibt eine Architekturkomponente, die
(RM 1) bei sämtlichen Subjekt/Objekt-Interaktionen involviert ist→ total mediation property
(RM 2) geschützt ist vor unautorisierter Manipulation→ tamperproofness
(RM 3) hinreichend klein und wohlstrukturiert ist, um formalen Analysemethoden zugänglich zu sein→ verifyability
Nach diesen Prinzipien gebaute Sicherheitsarchitekturkomponente:„Referenzmonitor“
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 12 -
Idee
→ 1 PDP (Politikimplementierung)viele PEPs (Interzeptoren, Politikdurchsetzung)
Filesystem Sockets Pipes
Proz.mgmt
open(filename, openmode)
{ ino=namei(filename);switch ino.objecttype of
file:
if (filesystem.checkpermission(ino,openmode))
{ fd=filesystem.open(ino, ...) ...}socket: ...
}
. . . (ca. 250 Systemaufrufe)
Betriebssystem-Schnittstelle (Application Programmer´s Interface (API))
5.1 Architekturprinzip ien
Security Server
Policy
System sicherheit, Som m er 2018 © w k - 13 -
Referenzmonitor Kernkomponente einer TCBumfasst typischerweise◆ Implementierung der Sicherheitspolitik(en) (PDPs)
• Modellzustand (z.B. ZM, Subjekt/Objekt-Attributierung)• Modelllogik (z.B. Autorisierungsschema)
◆ Durchsetzungsmechanismen (PEPs)
klammert in der Regel aus (wg. Komplexität und Größe, RM 3)◆ Authentisierung◆ kryptografische Mechanismen
◆ z.T. auch Modellzustand (z.B. ZSLs)
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 14 -
Folgen von (RM 3) für TCBsgeringe Größe, wenig Funktionengeringe Komplexität, einfache Funktionenstarke Isolationpräzise bestimmter Perimeter
TCBs
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 15 -
Highway to Hell:TCBTCB ImplementierungSicherheitsarchitekturBeachtung der Referenzmonitorprinzipien
heutiger IT Systeme, z.B.politikkontrollierte BSepolitikkontrollierte Anwendungssystemepolitikkontrollierte MiddlewareMikrokern basierte BSe ?
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 16 -
Politik kontrolliertes BS – Monolithischer BS KernPolitik auf Systemebene
Application
Process
Application
Process
Application
Process
Application
Process
OSFile System Policy Server
S={s ,s ,s }, O={o,o,so }...commandread(s,o)if readÎm(s,o)
enter(s,o) in h;"oÎO, (o,o)ÎC: delete read from m(s,o);"oÎO, o¹o: delete write inm(s,o);
end ifend...
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 17 -
Politik kontrolliertes BS – Monolithischer BS Kern
Application
Process
Application
Process
Application
Process
Application
Process
OSFile System Policy Server
S={s ,s ,s }, O={o,o,so }...commandread(s,o)if readÎm(s,o)
enter(s,o) in h;"oÎO, (o,o)ÎC: delete read from m(s,o);"oÎO, o¹o: delete write inm(s,o);
end ifend...
TCB – Funktionale Sicht
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 18 -
Politik kontrolliertes BS – Monolithischer BS Kern
Application
Process
Application
Process
Application
Process
Application
Process
OSFile System Policy Server
S={s ,s ,s }, O={o,o,so }...commandread(s,o)if readÎm(s,o)
enter(s,o) in h;"oÎO, (o,o)ÎC: delete read from m(s,o);"oÎO, o¹o: delete write inm(s,o);
end ifend...
TCB – Aus Sicht ihrer Implementierung
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 19 -
Politik kontrolliertes BS – Mikrokernarchitektur (Nizza)Politik auf Systemebene
Microkernel
Paravirtualized Legacy OS
Trusted Loader
TrustedName Server
SecurityPolicy
TrustedGUI…
LegacyApplication
LegacyApplication
LegacyApplication
SecureApplication
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 20 -
Politik kontrolliertes BS – Mikrokernarchitektur (Nizza)
Microkernel
Paravirtualized Legacy OS
Trusted Loader
TrustedName Server
SecurityPolicy
TrustedGUI…
LegacyApplication
LegacyApplication
LegacyApplication
Secure
Application
5.1 Architekturprinzip ien
TCB – Funktionale Sicht
System sicherheit, Som m er 2018 © w k - 21 -
Politik kontrolliertes BS – Mikrokernarchitektur (Nizza)
Microkernel
Paravirtualized Legacy OS
Trusted Loader
TrustedName Server
SecurityPolicy
TrustedGUI…
LegacyApplication
LegacyApplication
LegacyApplication
Secure
Application
5.1 Architekturprinzip ien
TCB – Aus Sicht ihrer Implementierung
System sicherheit, Som m er 2018 © w k - 22 -
Politik kontrolliertes Anwendungssystem
Politik auf Middleware-Ebene
OS OS
WebServices
Application
Process
Application
Process
S={s ,s ,s }, O={o,o,so }...commandread(s,o)
if readÎm(s,o)enter(s,o) in h;"oÎO, (o,o)ÎC:
delete read from m(s,o);"oÎO, o¹o:
delete write inm(s,o); end ifend...
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 23 -
in flow
Handlerm
Handler2
Handler1• • •
AxisEngine
instanciates
out flow
TransportSender
Handler1
Handler2
Handlern• • •
AxisEngine
instanciates
Client
Stub
SOAP Reply
CoordinatorOutInAxisOperation
instanciates
SOAP Request(by HTTP, JMS ...)
MCreq MCresp
MCresp
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 24 -
out flow
Handlerm
Handler2
Handler1• • •
AxisEngine
in flow
Handler1
Handler2
Handlern• • •
AxisEngine
MCreq
MCresp
SOAP Reply
SOAP Request
Axi
sSer
vlet
HTT
P/JM
STr
ansp
ort U
tiliti
es
TransportSender
Web
Ser
vice
MessageReceiver
MCreq
MCresp
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 25 -
in flow
Handlerm
Handler2
Handler1• • •
AxisEngine
instanciates
out flow
TransportSender
Handler1
Handler2
Handlern• • •
AxisEngine
instanciates
Client
Stub
SOAP Reply
CoordinatorOutInAxisOperation
instanciates
SOAP Request(by HTTP, JMS ...)
MCreq MCresp
MCresp
5.1 Architekturprinzip ien
TCB – Funktionale Sicht
System sicherheit, Som m er 2018 © w k - 26 -
out flow
Handlerm
Handler2
Handler1• • •
AxisEngine
in flow
Handler1
Handler2
Handlern• • •
AxisEngine
MCreq
MCresp
SOAP Reply
SOAP Request
Axi
sSer
vlet
HTT
P/JM
STr
ansp
ort U
tiliti
es
TransportSender
Web
Ser
vice
MessageReceiver
MCreq
MCresp
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 27 -
TCB – Aus Sicht ihrer Implementierung
OS
in flow
Handlerm
Handler2
Handler1• • •
AxisEngine
instanciates
out flow
TransportSender
Handler1
Handler2
Handlern• • •
AxisEngine
instanciates
Client
Stub
SOAP Reply
CoordinatorOutInAxisOperation
instanciates
SOAP Request(by HTTP, JMS ...)
MCreq MCresp
MCresp
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 28 -
OS
out flow
Handlerm
Handler2
Handler1• • •
AxisEngine
in flow
Handler1
Handler2
Handlern• • •
AxisEngine
MCreq
MCresp
SOAP Reply
SOAP Request
Axi
sSer
vlet
HTT
P/JM
STr
ansp
ort U
tiliti
es
TransportSender
Web
Ser
vice
MessageReceiver
MCreq
MCresp
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 29 -
Politik kontrolliertes AnwendungssystemPolitik auf Anwendungsebene
Application
Process
Application
Process
Application
Process
Policy ServerS={s ,s ,s }, O={o,o,so }...commandread(s,o)if readÎm(s,o)
enter(s,o) in h;"oÎO, (o,o)ÎC: deletereadfromm(s,o);"oÎO, o¹o: deletewriteinm(s,o);
end ifend...
OS
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 30 -
Politik kontrolliertes Anwendungssystem
Application
Process
Application
Process
OS
Application
Process
Policy Server
S={s ,s ,s }, O={o,o,so }
...
commandread(s,o)if readÎm(s,o)enter(s,o) in h;
"oÎO, (o,o)ÎC: delete read from m(s,o);
"oÎO, o¹o: delete write inm(s,o);
end ifend...
5.1 Architekturprinzip ien
TCB – Funktionale Sicht
System sicherheit, Som m er 2018 © w k - 31 -
Politik kontrolliertes Anwendungssystem
Application
Process
Application
Process
OS
Application
Process
Policy Server
S={s ,s ,s }, O={o,o,so }
...
commandread(s,o)if readÎm(s,o)enter(s,o) in h;
"oÎO, (o,o)ÎC: delete read from m(s,o);
"oÎO, o¹o: delete write inm(s,o);
end ifend...
5.1 Architekturprinzip ien
TCB – Aus Sicht ihrer Implementierung
System sicherheit, Som m er 2018 © w k - 32 -
Stand der Kunstzahlreiche eher schwache Realisierungen in◆ Standard-BSen
◆ Middleware◆ Applikationen
stärkere Ansätze◆ in Mikrokern basierten BS-Architekturen (e.g. L4/Nizza)
◆ in jüngeren BSen (e.g. SELinux, Trusted BSD, Open Solaris)
5.1 Architekturprinzip ien
System sicherheit, Som m er 2018 © w k - 33 -
5.2 Sicherheitsarchitekturen von Betriebssystemen
ProblemImplementierung der BS-TCB so, dass
Referenzmonitorprinzipiendie vielschichtigen Sicherheitsanforderungen der Anwendungssysteme
erfüllt werden
5.2 S icherheitsarchitekturen von Betriebssystem en
System sicherheit, Som m er 2018 © w k - 34 -
5.2.1 Nizza(TU Dresden)
ZieleSicherheitsarchitektur mit kleiner TCB◆ vollständige Kontrolle (RM 1)
◆ manipulationssichere Implementierung (RM 2)◆ kleine Implementierung (RM 3)
Wahrung der Funktionalität heutiger ◆ Standard-BSe
◆ Standard-Anwendungssysteme
5.2.1 N izza
System sicherheit, Som m er 2018 © w k - 35 -
KonzepteReferenzmonitorprinzipien: Trennung
◆ des BS◆ der Anwendungen
in sicherheitskritische und unkritische Komponenten→ präzise Identifikation einer (minimalen) TCB
Funktionalitätswahrung→ Paravirtualisierung von Standard-BSen
5.2.1 N izza
System sicherheit, Som m er 2018 © w k - 36 -
BS-Ebene
vertrauenswürdiger Mikrokern
vertrauenswürdige Basisdienste
nicht vertrauenswürdiges (paravirtualisiertes) BS
5.2.1 N izza
Microkernel
LegacyApplication
LegacyOperating System
Microkernel
Trusted Services
Network
Driver Loader GUISecure
Storage…
System sicherheit, Som m er 2018 © w k - 37 -
AnwendungsebeneAnfälligkeit für Fehler und Angriffe steigt mit funktionaler Komplexität→ Reduktion der Verwundbarkeit sicherheitskritischer Komponenten durch
AbspaltungIsolation
LegacyApplication
SecureComponent
5.2.1 N izza
EmailClient
EnigmailSigner
Beispiel Email-Klient■ unkritisch: Lesen/Schreiben/Senden von Mails■ kritisch: Signieren von Mails
System sicherheit, Som m er 2018 © w k - 38 -
Sicherheitsarchitektur
5.2.1 N izza
Microkernel
LegacyOperating System
EmailClient
EnigmailSigner
Trusted Services
NetworkDriver Loader GUI
Secure Storage…
System sicherheit, Som m er 2018 © w k - 39 -
Sicherheitsarchitektur
TCB
Größe der TCB: 105.000 LOCMikrokern (L4/Fiasco): 15.000 LOC
vertrauenswürdige Dienste: 35.000 LOCEnigmail Signer: 55.000 LOC
5.2.1 N izza
L4 Microkernel
EmailClient
EnigmailSigner
ParavirtualisiertesL4Linux
Trusted Services
NetworkDriver Loader GUI Secure
Storage…
System sicherheit, Som m er 2018 © w k - 40 -
ErgebnisseReduktion der Code-Größe der TCB um 2 Größenordnungen(100.000 LOC vs. 10.000.000 LOC)Wahrung der Funktionsfähigkeit von Standard-BSen und Applikationen
Kosten(moderate) PerformanzeinbußenParavirtualisierung von Standard-BSen
Dekomposition von Anwendungssystemen
5.2.1 N izza
System sicherheit, Som m er 2018 © w k - 41 -
5.2.2 Security Enhanced Linux
ZielBetriebssystem mit leistungsfähigen Sicherheitskonzepten
state-of-the-art Betriebssystem
state-of-the-art Sicherheitsparadigmen
Ideepolitikgesteuerter (Linux) BS-Kern
Technischer Ansatz
SELinux =
Linux (DAC, IBAC)
MAC, RBAC, ABAC, TAM, MLS
5.2.2 Security Enhanced Linux
System sicherheit, Som m er 2018 © w k - 42 -
Sicherheitspolitiken in SELinux (vgl. auch 3.3.2)
Anwendungsdomäne: ZS-Politiken für BSeRealisierung: neue BS-Abstraktion (die erste seit 40 Jahren)nicht gänzlich unähnlich dem Prozessparadigma◆ Spezifikation
• eines Prozesses:Programm; Algorithmus in formaler Notation (C++, Java, ...)
• einer Sicherheitspolitik:Sicherheitsmodell; Regeln in formaler Notation (HRU, BLP, Skippy, ...)
◆ Laufzeitumgebung• eines Prozesses:
Prozessmanager; Ablaufumgebung für Programme• einer Sicherheitspolitik:
Security Server; Ablaufumgebung für Sicherheitsmodelle
5.2.2 Security Enhanced Linux
System sicherheit, Som m er 2018 © w k - 43 -
SELinux-Architektur
Security Server (policy decision point, PDP)Laufzeitumgebung für Politik in Schutzdomäne des Kerns
Interzeptoren (policy enforcement points, PEPs)■ vollständige Interaktionskontrolle in den Objektmanagern (Teil des „Linux
Security Module Frameworks“)
SocketsDateisystemeProzess-management
AnwendungsprozessAnwendungsprozess AnwendungsprozessAnwen-dungs-ebene
Betriebs-system
Systemweites Ressourcenmanagement
Prozessor-Ressourcen
Speicher-Ressourcen
Kommunikations-Ressourcen
Betriebssystem-Schnittstelle (Application Programmer‘s Interface (API))
BS-Dienste
. . . Security ServerPolicy
Prozess-Management
Datei-systeme
Sockets
5.2.2 Security Enhanced Linux
System sicherheit, Som m er 2018 © w k - 44 -
Implementierungskonzepte
Referenzmonitorprinzipien■ vollständige Kontrolle sicherheitsrelevanter Interaktionen
→ Platzierung der PEPs (LSMs): Integration in die Objektmanager■ Manipulationssicherheit der Politikimplementierung
→ Platzierung des PDPs: Integration in den BS-Kern (security server)
PolitikunterstützungSicherheitspolitiken erfordern
Authentizität der Entitäten: eindeutige Subjekt-/Objektidentifikationen→ security identifier („SID“)politikspezifische Entitätenattribute (Typ, Rolle, MLS Label)→ security contextWeg: funktionale Erweiterung der Objektmanager
5.2.2 Security Enhanced Linux
System sicherheit, Som m er 2018 © w k - 45 -
Implementierungskonzepte
ProblemIn Linux,
Subjekt/Objekt Ids sind◆ Weder eineindeutig◆ Noch gleichartig
→ security identifier (SID)politikspezifische Subjekt/Objekt-Attribute (type, role, MLS label)◆ nicht Teil der Subjekt/Objekt-Metadaten
→ security context
→ Lösung: die Objektmanager helfen
5.2.2 Security Enhanced Linux
System sicherheit, Som m er 2018 © w k - 46 -
Authentizität der EntitätenObjektmanager helfen: implementieren injektive Abbildung SÈO → SID
■ Generierung der SID durch Security Server
■ Mapping der SIDs auf Objekte durch Objektmanager
Objektmanager
(Objekt→SID)-Map
Security Server
SID Anfrage
ObjA SID
A
ObjB SID
B NewObj
neue SID anfordern mit(SIDS, object type)
PolitikNeue SID
5.2.2 Security Enhanced Linux
Subjekt (mit SIDS)create object
System sicherheit, Som m er 2018 © w k - 47 -
Attributierung der EntitätenSicherheitspolitik implementiert injektive Abbildung SID → security context
Objektmanager
(Objekt→SID)-Map
Security Server
(SID→Context)-Map
SID Anfrage
ObjA SID
A
ObjB SID
B NewObj
neue SID anfordern mit(SIDS, object type)
Politik
Attributierungsregeln
Neue SID
■ Erzeugung des security contexts nach politikspezifischen Attributierungsregeln
■ Eintrag in SID→security context Mapping-Tabelle
5.2.2 Security Enhanced Linux
Subjekt (mit SIDS)
create object
System sicherheit, Som m er 2018 © w k - 48 -
Security Contextumfasst
Standard-Entitätenattribute wie z.B.
◆ User Id
◆ Rolle
◆ Typ (user_t, tomCat_t, …)
◆ Klasse (process, file, …)
politikspezifische Entitätenattribute wie z.B.
◆ Vertraulichkeitsklasse (BLP-Label)
5.2.2 Security Enhanced Linux
Security Server
SID→context map
Politik
Attributierungsregeln
System sicherheit, Som m er 2018 © w k - 49 -
Problem: die Security Contexts persistenter EntitätenPersistenzeigenschaft einer Entität ist Sicherheitspolitik unbekannt→ Persistenz der security contexts ist Aufgabe der ObjektmanagerLayout der Metadaten persistenter Speicher (z.B. I-Nodes in Dateisystemen) muss kompatibel zu Standard-Layout bleiben→ Integration der security contexts in existierende
Metadatenstrukturen persistenter Objekte (I-Nodes) problematisch
5.2.2 Security Enhanced Linux
System sicherheit, Som m er 2018 © w k - 50 -
Lösungpersistente Objekte erhalten zusätzlich eine (Objektmanager-lokale) persistente SID: „PSID“
Objektmanger bilden diese auf SID ab
$ 3 versteckte Bereiche (» Dateien) auf persistenten Speichermedien (Dateisystemen)
◆ security context des Dateisystems selbst
◆ bijektive Abbildung I-Node → PSID
◆ bijektive Abbildung PSID → security context
5.2.2 Security Enhanced Linux
File Object Manager
SID/PSID
Map
Inode T
able
FilesystemSecurity Context
I-Node/PSIDMap
PSID/Security
Context
Files and
Directories
System sicherheit, Som m er 2018 © w k - 51 -
Access Vector Cache (AVC)lokalisiert in Objektmanagern (user-level) bzw. im Security Server
speichert Entscheidungen des Security Servers
Objektmanager
Performanz (+5%...)
Security Server
Objekt-Zugriff
PEP:AccessCheck
(SIDs, SIDo, Perm)
Politik
AVC
Subjekt (mit SIDS)
5.2.2 Security Enhanced Linux
Anfrage
Entscheidung
System sicherheit, Som m er 2018 © w k - 52 -
Zusammenfassung SELinux
Motivationveraltete und schwache Sicherheitsmechanismen in heutigen Standard-BSen
Folgeunzulängliche und unangemessene Spezifikationsmöglichkeitenzahlreiche Sicherheitslücken
ReaktionSicherheitspolitiken als neue BS-Abstraktion→ politikkontrolliertes BS: DAC & MAC, IBAC, RBAC, ABAC, TAM, MLS
5.2.2 Security Enhanced Linux
System sicherheit, Som m er 2018 © w k - 53 -
Einhaltung der Referenzmonitorprinzipien1. Total Mediation Property (Platzierung der PEPs)
hmm ...(noch?) manuell
5.2.2 Security Enhanced Linux
SocketsDateisystemeProzess-management
Systemweites Ressourcenmanagement
Prozessor-Ressourcen
Speicher-Ressourcen
Kommunikations-Ressourcen
Betriebssystem-Schnittstelle
BS-Dienste
. . . Security ServerPolicy
Prozess-Management
Datei-systeme
Sockets
System sicherheit, Som m er 2018 © w k - 54 -
2. TamperproofnessGrundsätzliches Problem monolithischer (SAS-) Architekturen→ TCB-Implementierung verletzbar durch gesamten BS-Code
Security Serversämtliche ObjektmanagerSpeichermanagementIPC-ImplementierungE/A-System
Es geht auch kleiner: Nizza
5.2.2 Security Enhanced Linux
SocketsDateisystemeProzess-management
Systemweites Ressourcenmanagement
Prozessor-Ressourcen
Speicher-Ressourcen
Kommunikations-Ressourcen
Betriebssystem-Schnittstelle
BS-Dienste
. . . Security ServerPolicy
Prozess-Management
Datei-systeme
Sockets
System sicherheit, Som m er 2018 © w k - 55 -
3. VerifyabilityGröße und Komplexität der Politik (Referenzpolitik » 50.000 Regeln)→ Werkzeug gestützte Analyse
Generalitätsanspruch der Politik-RTEVollständigkeit der PEP-Platzierung
Isolation der Politik
5.2.2 Security Enhanced Linux
SocketsDateisystemeProzess-
management
Systemweites Ressourcenmanagement
Prozessor-Ressourcen
Speicher-Ressourcen
Kommunikations-Ressourcen
Betriebssystem-Schnittstelle
BS-Dienste
. . . Security ServerPolicy
Prozess-Management
Datei-systeme
Sockets
System sicherheit, Som m er 2018 © w k - 56 -
StubStub
Sicherheits-politik
Sicherheits-politik
5.3 Sicherheitsarchitekturen verteilter Systeme
Szenario
Verteilte Middleware-Plattform (e.g. CORBA, Web Services)
Klient Objekt
AuditServerTicket
ServerAuthenti-sierungsserver
BS-Ebene
5.3 S icherheitsarchitekturen verte ilter System e
BS-Ebene BS-Ebene
System sicherheit, Som m er 2018 © w k - 57 -
...msg.subject=myCredentials;msg.method_Id=writeAssignment_Id;msg.params= myHomework;send(server, msg);...
...Kurs.writeAssignment(myHomework);...
5.3.1 CORBA
Integration von Sicherheitspolitiken
Klienten-Stubmit
Proxy-Objekt(hier ohne
PEP und PDP)
Klient
msg: myCredentials
writeAssignment_Id
myHomework
5.3.1 C O R BA
System sicherheit, Som m er 2018 © w k - 58 -
PDP: CORBA Policy Object (Skizze)
Server-
Skeleton
Server
class fernUniPolicy{ public:
bool check(msgType msg)
{ if (s=checkCredentials(msg.myCredentials))
{ o=msg.myHomework;
switch (msg.method_Id)
{ case writeAssignment_Id:
{ if (write Î m[s,o]) m[s,o] += read;
return (write Î m[s,o]);}
case readSample_Id:
{ if (read Î m[s,o])m[s,o] -= write;
return (read Î m[s,o]);}
default: return false;
}
} else return false;
}
private:
rightsetType m[subjectType,objectType];}
PEP:
„if (fernUniPolicy.check(msg)) ...“
msg: myCredentials
writeAssignment_id
myHomework
5.3.1 C O R BA
System sicherheit, Som m er 2018 © w k - 59 -
Integration von SicherheitspolitikenBeispiel: Apache Axis-2 Webserver
5.3.2 Web Services
5.3.2 W eb Services
H a n d le r
m
H a n d le r
2 Policy• • •
A x is E n g in e
H a n d le r
1
H a n d le r
2 Policy• • •
A x is E n g in e
M C req
M C resp
S O A P R e p ly
S O A P R e q u e s t
Ax
isS
erv
let
HT
TP
/JM
S
Tra
ns
po
rt U
tilit
ies
T r a n s p o r t
S e n d e r
We
b S
erv
ice
M e s s a g e
R e c e iv e r
M C req
M C respPolicy
H a n d le r
2
H a n d le r
1• • •
A x is E n g in e
T r a n s p o r t
S e n d e rPolicy
H a n d le r
2
H a n d le r
n• • •
A x is E n g in e
C l ie n t
Stu
b
S O A P R e p ly
C o o r d in a to r
O u tIn A x is O p e r a t io n
S O A P R e q u e s t
( b y H T T P , J M S . . . )
M C reqM C resp
M C resp
System sicherheit, Som m er 2018 © w k - 60 -
5.3.3 Kerberos
Authentisierungs- und Autorisierungsarchitektur für verteilte Systeme mit geschlossenen Benutzergruppen
Szenarioorganisationseigenes verteiltes IT-SystemArbeitsplatzrechner und Server 2 Kerberos-Server◆ Authentisierungsserver (AS)◆ Autorisierungsserver (TGS)
■ entwickelt im MIT-Projekt Athena, ab1986■ Konzepte sind u.a. Teil der Spezifikation der Basic CORBA Security Architecture■ Entwicklungsumgebung: 650 Workstations, 65 Server, 5000 Benutzer (1988)
lokalesRechnernetz
AS
TGS
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 61 -
Architekturkomponenten
Authentication Server (AS)◆ authentisiert Nutzer
• Grundlage: gemeinsamer (symmetrischer) Schlüssel von Nutzer und AS
• Ergebnis: Personalausweis („authenticator“)◆ autorisiert Nutzung des TGS
• Grundlage: gemeinsamer Schlüssel von AS und TGS• Ergebnis: Capability („ticket“) für TGS
Ticket Granting Server (TGS)◆ stellt Tickets für alle Server aus
• Grundlage: gemeinsamer Schlüssel von TGS und jeweiligem Server
• Ergebnis: Ticket(s) für Server(s)
Kerberos Datenbank◆ enthält je Benutzer Abbildung Name → Authentisierungsschlüssel◆ wird benutzt vom AS◆ ist mehrfach repliziert (Verfügbarkeit, Skalierbarkeit)
TGS
AS
5.3.3 Kerberos
Daten-bank
System sicherheit, Som m er 2018 © w k - 62 -
Überblick: Typische Nutzung
1. Authentisierung + Anforderung TGS-Ticket
2. Personalausweis, TGS-Ticket3. Anforderung weiterer Server-Tickets
4. Server-Tickets5. Dienstanforderung: Server treffen Entscheidung basierend auf
◆ Personalausweis des Klienten◆ Server-Ticket◆ (eventuell) lokale Sicherheitspolitiken
12
5
TGSAS
Server-Zoo
Daten-bank
Anna
43
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 63 -
Inside Kerberos Tickets
Ticketswerden vom Ticket Granting Server ausgegeben
spezifizieren Nutzungsrecht genau eines Klienten bzgl. genau eines Servers (persönliche Capabilities)haben Lebenszeit (Erschwerung kryptographischer Angriffe)
» 1 Tag; Abwägung sicher / bequem◆ kurz: unbequem, sicher: wenn Ticket gestohlen wird, gilt es nicht mehr lange◆ lang: unsicher, bequem: nicht so oft neues Ticket besorgen
sind in diesem Rahmen mehrfach benutzbar
enthalten einen Sitzungsschlüsselsind vom TGS versiegelt mit Schlüssel des betreffenden Servers (MAC)
TKlient/Server={Klient, Server, Klient.Netzadresse, Zeitstempel, Lebenszeit, SessionKeyKlient/Server}KTGS/Server
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 64 -
Maßnahmen gegen Ticket-MissbrauchManipulation durch Klienten zwecks Rechteerschleichung für anderen Server
→ Maßnahme: Integritätssicherung durch MAC mittels KTGS/Server
Abfangen und Verwendung durch Dritte
→ Maßnahme: Personalisierung durch ◆ Name und Netzadresse des Klienten in Verbindung mit
• begrenzter Lebenszeit• authenticator des Klienten →
5.3.3 Kerberos
TKlient/Server={Klient, Server, Klient.Netzadresse, Zeitstempel, Lebenszeit, SessionKeyKlient/Server}KTGS/Server
System sicherheit, Som m er 2018 © w k - 65 -
Inside Kerberos Authenticators
AuthenticatorsNachweis der Identität eines Klienten gegenüber Server
erzeugt mittels Sitzungsschlüssel Klient/Server→ können erzeugt und geprüft werden durch
◆ Klient (ohne Hilfe des AS, da er Sitzungsschlüssel kennt (s.u.))◆ Server
◆ TGS (vertrauenswürdig)können nur ein einziges Mal verwendet werden
→ Schutz vor Replay-Angriff durch Frische-Prüfung
AKlient={Klient, Klient.Netzadresse, Zeitstempel} SessionKeyKlient/Server
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 66 -
Inside Kerberos Authenticators
Anmerkung zur Implementierung der 1x-Nutzungsemantikfreies Nonce (statt Zeitstempel)
◆ präzise Implementierung der einmaligen Nutzung ist teuer(Buchführung in jedem Server, lebenslang, ähnlich TANs)
Zeitstempel als Nonce◆ gibt authenticator beschränkte (sehr kurze) Lebensdauer
◆ führt zur Notwendigkeit synchronisierter Uhren aus Sicherheitsgründen
AKlient={Klient, Klient.Netzadresse, Zeitstempel} SessionKeyKlient/Server
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 67 -
Kerberos Login 1/3
Gesamtablauf
TGS Ticket mitTGS Sitzungsschlüssel
Name, Passwort Auth. RequestAnna Kerberos
AS
Anna, TGS
2. Anna´s Workstation stellt Anfrage an AS
Im Einzelnen:1. Anna identifiziert sich
AnnaAnna
KerberosAS
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 68 -
Kerberos Login 2/3
3. Der ASerzeugt frischen Zeitstempel
erzeugt frischen Sitzungsschlüssel für Anna´s Kontakt zum TGS: SessionKeyAnna/TGS
erzeugt Anna´s Ticket für TGS und verschlüsselt dies mit KAS/TGS (dadurch durch Anna nicht modifizierbar):
TicketAnna/TGS={Anna, TGS, ..., SessionKeyAnna/TGS}KAS/TGSverschlüsselt dies alles mit KAnna/AS (dadurch kann nur Anna aus der Botschaft den SessionKey und das TGS-Ticket herauslesen)
{TGS, Zeitstempel, SessionKeyAnna/TGS, TicketAnna/TGS}KAnna/AS KerberosAS
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 69 -
Kerberos Login 3/3
4. Anna´s Workstationbesitzt nun {TGS, Zeitstempel, SessionKeyAnna/TGS, TicketAnna/TGS}KAnna/ASfordert Passwort von Anna an; Anna:
■ berechnet KAnna/AS aus Passwort mittels kryptografischer Hash-Funktion■ entschlüsselt damit die obige vom AS erhaltene Botschaft
Resultat: Anna´s Workstation besitzt■ Sitzungsschlüssel für TGS-Session: SessionKeyAnna/TGS
■ Ticket für TGS: TicketAnna/TGS■ die Mittel, einen authenticator zu erzeugen
Anna´s PasswortAnna
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 70 -
Server nutzen 1/3
Authentisierung (beidseitig)
2 Schritte1. Authentisierung des Klienten gegenüber dem Server 2. Authentisierung des Servers gegenüber dem Klienten (optional)
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 71 -
Server nutzen 2/3
1. Authentisierung des KlientenVoraussetzungen
Anna besitzt Session Key SessionKeyAnna/Server
Anna besitzt Serverticket TicketAnna/Server
1.a) Anna konstruiert authenticatorAAnna = {Anna, Anna´s Netzadresse, Zeitstempel}SessionKeyAnna/Server
Dies kann nur Anna, denn nur sie kennt SessionKeyAnna/Server
1.b)
1.c) Server entschlüsselt Ticket und erhält session key; damit kann er AAnna entschlüsselnund prüfen:◆ Frische◆ Übereinstimmung der Namen im Ticket und im authenticator◆ Herkunftsadresse im authenticator mit der von seiner Netzwerk-Hardware genannten
TicketAnna/Server, AAnnaAnna
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 72 -
Server nutzen 3/3
2. Authentisierung des Servers
kann nur jemand, der den mit Anna gemeinsamen Sitzungsschlüssel SessionKeyAnna/Server kennt
diesen besitzt nur der richtige Server, da nur dieser den Sitzungsschlüssel aus dem TicketAnna/Server={Anna,Server,...,SessionKeyAnna/Server}KTGS/Serverextrahieren kann
{Zeitstempel+1}SessionKeyAnna/ServerAnna
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 73 -
Ticket für einen Server besorgen
Ticketsgelten für Paar (Klient, Server)
werden (bis auf TGS-Ticket selbst) ausschließlich vom TGS ausgegeben
Ticketanforderung an TGS: (gewünschter Server, TGS-Ticket, Authenticator)
TGS:■ prüft TicketAnna/TGS und Authenticator
■ generiert Sitzungsschlüssel für Klient und Server: SessionKeyAnna/Server
■ generiert Ticket: TicketAnna/Server
■ verschlüsselt beides mit gemeinsamen Sitzungsschlüssel
Server, TicketAnna/TGS, AAnnaAnna
KerberosTGS
AnnaKerberos
TGS
5.3.3 Kerberos
{Server, SessionKeyAnna/Server, TicketAnna/Server}SessionKeyAnna/TGS
System sicherheit, Som m er 2018 © w k - 74 -
Kerberos Zusammenfassung
5.3.3 Kerberos
Leistungen?Unterschiede zu nicht verteilten Sicherheitsarchitekturen?PDPs und PEPs?Größe der TCB?RM-Prinzipien?
lokalesRechnernetz
AS
TGS
System sicherheit, Som m er 2018 © w k - 75 -
Verteilte Authentisierungs- und Autorisierungsarchitektur2 spezialisierte Security-Server◆ Authentisierung
◆ Autorisierung
Einsatz kryptografischer Mechanismen◆ Authentisierung◆ Vertraulichkeit + Integrität der Kommunikation
◆ Integrität + Authentizität der Tickets und Authenticators
Kerberos-TCB: BS +◆ Authentication Server
◆ Ticket Granting Server◆ Kerberos Datenbank
◆ sämtliche PDPs und PEPS auf den Servern◆ Zeitserver (NTP: signierte Zeitstempel!)
5.3.3 Kerberos
System sicherheit, Som m er 2018 © w k - 76 -
5.4 Zusammenfassung
(Fast) Alle heutigen TCBsgroßinhomogenverteiltpräzise Perimeterangabe schwierig
SicherheitsarchitekturproblemeEinhaltung der Referenzmonitorprinzipien
Fallbeispiele (PEPs, PDPs, SA, RM-Prinzipien)NizzaSELinuxCORBA, Web Services, Kerberos
→ gewaltige Herausforderungen!5.4 Zusam m enfassung
System sicherheit, Som m er 2018 © w k - 77 - System sicherheit
SystemsicherheitWinfried E. KühnhauserSommersemester 2018
F in ished
System sicherheit, Som m er 2018 © w k - 78 -
Was können wir jetzt?
System sicherheit
Schwachstellenund Risiken
Policy Engineering• Rolle der
Sicherheitspolitiken• Modellierung• Analyse• Spezifikation
Implementierung• TCBs• Referenzmonitore• Sicherheits-
architekturen
SicherheitspolitikenModellierung und Spezifikation
Sicherheitsarchitekturen
Sicherheitsanforderungen
Sicherheitsmechanismen
System sicherheit, Som m er 2018 © w k - 79 -
Was wir nicht gemacht haben, aber trotzdem wichtig istNetzsicherheit → Schäfer
Kryptographie → Dietzfelbinger
Managementaspekte → Stelzer (Master)
technische Aspekte: Firewalls, Virenscanner, IDSs, ...
System sicherheit
System sicherheit, Som m er 2018 © w k - 80 -
Hot Topics
„Things should be fun to use“
Policy EngineeringModel EngineeringMethoden und Werkzeuge◆ Modellanalyse, -spezifikation, -implementierung
Multipolitikensysteme◆ Politikkoordination
◆ Sicherheitsarchitekturen
Politikimplementierungkleine, präzise identifizierte TCBsReferenzmonitore, die ihren Namen verdienen
System sicherheit
System sicherheit, Som m er 2018 © w k - 81 -
Wie kann es weitergehen?
ProseminarModel Engineering, Methoden und Werkzeuge, Politikimplementierung
Bachelor-ArbeitenEntwicklung von Komponenten für die Security Policy Engineering Workbench◆ Sicherheitsmodelle für spezifische Einsatzszenarien; e.g.
◆ Analysealgorithmen; e.g. DEPSEARCHWS
◆ Spezifikationssprachen und ihre Compiler; e.g. CORPS
Master InformatikStudienschwerpunkt IT-Sicherheit
Security EngineeringSchutz von KommunikationsinfrastrukturenSicherheitsmanagement
System sicherheit