Access-Vector-Cache

Am einfachsten wäre es sicherlich, wenn der Object-Manager bei jedem Zugriff den Security-Server fragen würde, ob der Zugriff erlaubt ist. Dies wäre jedoch sehr langsam und daher nicht sinnvoll. Die Flask-Architektur erlaubt daher das Caching der Entscheidungen in dem Object-Manager.

Das AVC-Modul wird von allen Object-Manager gemeinsam genutzt. So kommunizieren die Object-Manager nicht direkt mit dem Security-Server, sondern über den AVC.

Muss nun der Zugriff eines Subjektes auf ein Objekt evaluiert werden, sendet der Object-Manager einen Access-Vector bestehend aus dem Subject-Security-Context, dem Object-Security-Context und dem Zugriff an den AVC. Dieser prüft, ob die entsprechende Entscheidung bereits im AVC gespeichert ist. Ist das nicht der Fall, wird der Access-Vector an den Security-Server weitergesendet. Dieser prüft und entscheidet über den Zugriff und sendet die Entscheidung zurück an den AVC. Aus Geschwindigkeitsgründen kann der Security-Server mehrere (auch zusätzliche nicht angefragte) Entscheidungen gleichzeitig an den AVC senden. Dieser wird sie für zukünftige Zugriffe speichern. So wird zum Beispiel immer ein kompletter Access-Vector zurückgeliefert. Der Access-Vector enthält dann für das betroffene Objekt alle Zugriffe, die das Subjekt durchführen darf.

Hier erklärt sich dann auch, warum die Protokollmeldungen von SELinux nicht SELinux sondern AVC im Namen tragen. Das Subsystem, welches die Meldung auslöst, ist der AVC.