Sicherheit im Betriebssystem

These: Sichere Applikationen brauchen zwingend ein sicheres Betriebssystem [LSMTTF1998]

( [LSMTTF1998] sagt, dass es diese These schon 25 Jahre gibt, d.h. seit 1973 - also schon 40 Jahre - diese HTML Seite wurde 2013 geschrieben.
Die Anwender müssen Sicherheit forderen - auch bei einem gewissen kommerziell sehr verbreiteten System.)

Merkmale:

erzwungende Sicherheit (mandatory security)

trusted Path

es darf keine Software geben, die vertrauenswürdige Software ersetzt und imitiert ,d.h. als solche ausgibt (impersonate)

protected path

• gegenseitig authentifizierter Kanel zwischen softwarekomponenten
• stellt sicher, dass wichtige Ssystemfunktionalität nicht vergetäscht werden kann.

Betriebsystem kann einfacher und effiziener die Unterst¨tzung bieten

Wichtige Bemerkungen aus [LSMTTF1998]

• Mit virtuellen Maschienen (Java, .NET,Flash,...) verschwimmt die Grenze zwischen Daten und Code (Code → Unentscheidbarkeit des Halteprobems → Unentscheidbarkeit des Virenproblems!)
• Die Merkmale allein reichen nicht, sondern
  1. sie müssen korrekt implementiert sein (beweisbar)
  2. es muss sicher beweisen sein, dass die Merkmale die beabsichtigen Sicherhaitsanforderungen des Systems erfüllen.

Fluke

• Sicherheitsmechanismus: vom Kern verwaltete Capabilities

Mechanismen

Capabilities

Zugriffsausweise, die spezielle Operationen erlauben. Nutzer kann sie einschränken und weitergeben

Essay über Capabiliies in EROS

en.Wikipedia

Kritik:

• Verbreitung der Capabilities kaum kontrollierbar [SSLHAL1999]
• wenig Flexibilität ??? [SSLHAL1999]

Literatur

[LSMTTF1998] The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments 1998

[SSLHAL1999] The Flask Security Architecture: System Support for Diverse Security Policies

Cohen: "Protection in the Hydra-Operating System