FLASK - Flux Advanced Security Kernel

Architektur

• Ziel Flexibilität: Der Security-Server kann ausgetauscht werden
• Ziel: application Tranparency (Anwendung sieht nichts)
• Ziel: defence in depth
• Ziel: ease of assurance - einfache Sicherheitsverifizierung
• Ziel: minimale Leistungseinbussen

Schnittstelle zwischen Objektmanager und Sicherheitsserver:

• Zugriffsabfrage: Ob Subjekt auf ein Objekt zugreifen darf (grant)
• Labeling: Einem Objekt werden Sicherhetsattribute zugewiesen
• polyinstantiation-Entscheidung: welches Element eines polyinstanziieten Betriebsmittel

AVC Access Vector Cache

im Object Manager um die Entscheidungen zu cachen. Es können auch erwartete Entscheidungen schon vor dem Eintreffen durch Clients gespeichert werden.
99% aller Anfragen decken die AVC ab und erreichen daher nicht den Securty-Server

Objectmanager als Beobachter des Sicherheitsservers

damit beobachtet der Objectmanager Rechteänderungen

Object-Manager

• Mechanismus um Labels Objekten zuzuweisen
• Kontrollpolitik,um Sicherheitsentscheidungen umzusetzen (Spezifikation und implementierung)
  Diese Kontrollpolitik muss die Reaktion einer allgemeinen Sicherheitsbedrohung sein. Die Kontrollpolitik muss konfigurierbar sein, um n Verscheidenen Stufen auf eine Bedrohung zu reagieren
• muss die Beobachter-Schnittstelle zum Sicherheitsserver implementierung und auf Politikänderungen reagieren.
• bei Polyinstanziierung die richtige Auswahl des gewählten Betriebsmittel implementiert werden.

Sicherheitsserver

Aufgaben:

• macht die Entscheidungen gemäß der Sicherheitspolitik
• verwaltet die Abbildung zwischen SIDs und Security-Kontexten
• gibt SIDs für neugeschaffene Objekte aus
• hilft Objektmanagern, ihren AVC zu verwalten
• meistens kann er Politiken laden und ändern.

Performannce: SM kann seine Entscheidungen in einem AVC speichern, um die Abfragezeit zuminimieren.

Refektion: Ein Security-Service ist ein Objektmanager bezüglich Rechten, und muss selber die Rechte dieser Objekte verwalten.

Beim verteiltem System braucht jeder Knoten seinen eigenen Securityserver, für die lokalen Objekte. Dies ist beim Booten wichtig, damit gleich alles sicher ist. Die lokalen Sicherheitsserver müssen sich im Gesamtsystem koordinieren.

Begriffe

security policy

security attribut

security context

eine Menge von security-Attributen. Ein Objekt wird einem Secutity-Context zugeordnet.
Policy-unabhänig, variabel langer String (→ kann von Applikationen und dem Nutzer mit dem Verständnis der Sicherheitspolitik interpretiert werden ). Konkretisierungen:

• Nutzer-Identität
• Klassikikaionsebene (vertraulich, geheim, streng geheim)
• Rolle
• Typerzwingung

(Designfrage:

• ein uninterprierter (opaque) String grenzt die möglichen Politiken aus sich des OM nicht ein
• aber: zum kennzeichnen(labeln) und für Suchen für Entscheidungen währen ineffizient und Erhöhen die Notwendigkeit, politikspezifische Logik in die Objektmanager einbauen zu müssen

)

Security identifier SID

• wird vom SecurityServer zu einem Security Context abbgebildet.
• z.B. 32-But-wert, kann nur vom Security-Server interpretiert werden.
• Besitz oder Kenntnisgewährt keine Autorisierung für diesen Security-Context.
• SIDs sind nicht persistent, d.h. nach reboot können sie anders sein, sind nicht bei anderen Sicherheitsservern gütig (andere Knoten)

Bei der Erzeugung eines Objekts wird eine SID zugewiesen, die den Sicherheitskontext repräsentiert, in dem das Objekt erzeugt wurde, z.B. Kontext des Verzeichnises und dem Security Context des Kunden. Die Berechnung des SID muß der Sicherheitsserver machen, die Berechnung ist aus Politik abhängig.

Identifizierung der Clients und Server

Objectmanagers müssen die SID eines Clients als Grundlage für dieSicherheitsentscheidung wissen. Allerdings sollen auch Clients und Server auch beeinflußen können: Einschränkung der Rechte (z.B. nur lesen bei pinzipeller Schreiberlaubnis) oder zur Anonymisierung im Netzwerk

bei Flask wird

• die SID des Clients mit dem IPC-Request geliefert.
• Der Client kann die SID des Servers über einen Kernaufruf über die beim Zugriff genutzte Capability erfragen
• Der Client kann beim IPC eine andere effektive SID angeben.
• Der Server kann bei der Vorbereitung zum Requestempfang auch eine eigene SID festlegen.

Die Alternativen sind ein kompiziertes und potentiell teuere externe Authentifikationsprotokolle.

Rücknahme von Rechten

Politikänderungen müssen transaktional in einem 2 Phasen-Commit-Protokoll erfolgen, neben dem Sicherheitsserver können mehrere Opbjektmanager beteiligt sein.

Implementierungen bzw. Auswirkungen des Flask-Konzepts

• SELinux ist die Portierung des Flask in das monolitischen Kern Linux