Modulname: mac_biba.ko
Parameter für die Kernelkonfiguration:
options MAC_BIBA
Bootparameter: mac_biba_load="YES"
Das Modul mac_biba(4) lädt die MAC Biba Richtlinie. Diese ähnelt stark der MLS Richtlinie, nur das die Regeln für den Informationsfluß ein wenig vertauscht sind. Es wird in diesem Fall der absteigende Fluß sicherheitskritischer Information geregelt, während die MLS Richtlinie den aufsteigenden Fluß regelt. In gewissen Sinne treffen dieses und das vorangegangene Unterkapitel also auf beide Richtlinien zu.
In einer Biba-Umgebung wird jedem Subjekt und jedem Objekt ein „Integritäts“-Label zugeordnet. Diese Labels sind in hierarchischen Klassen und nicht-hierarchischen Komponenten geordnet. Je höher die Klasse, um so höher die Integrität.
Die unterstützten Labels heißen
biba/low
, biba/equal
und
biba/high
. Sie werden im Folgenden
erklärt:
biba/low
ist die niedrigste Stufe der
Integrität, die einem Objekt verliehen werden kann. Wenn sie
einem Objekt oder Subjekt zugeordnet wird, kann dieses auf Objekte
oder Subjekte, die biba/high markiert wurden, zwar lesend zugreifen,
nicht jedoch schreibend.
Das Label biba/equal
ist, wie der aufmerksame
Leser sicherlich schon ahnt, für die Ausnahmen dieser Richtlinie
gedacht und sollte nur diesen Ausnahmen entsprechenden Objekten
verliehen werden.
biba/high
markierte Subjekte und Objekte
können Objekte niedrigerer Stufe schreiben , nicht jedoch lesen.
Es wird empfohlen, dass dieses Label an Objekte vergeben wird, die
sich auf Integrität des gesamten Systems auswirken.
Biba stellt bereit:
Hierarchische Integritätsstufen mit einem Satz nichthierarchischer Integritätskategorien;
Festgeschriebene Regeln: kein „Write-Up“, kein „Read-Down“ (der Gegensatz zu MLS - ein Subjekt erhält schreibenden Zugriff auf Objekte gleicher oder geringerer Stufe, aber nicht bei höherer, und lesenden Zugriff bei gleicher Stufe oder höerer, aber nicht bei niedrigerer);
Integrität (es wird die Echtheit der Daten gewährleistet, indem unangemessene Veränderungen verhindert werden);
Eine Abstufung der Gewährleistung (im Gegensatz zu MLS, bei der eine Abstufung der Vertraulichkeit vorgenommen wird).
Folgende sysctl
Parameter werden zur Nutzung der
Biba-Richtlinie angeboten:
security.mac.biba.enabled
zum
Aktivieren/Deaktivieren der Richtlinie auf dem Zielsystem.
security.mac.biba.ptys_equal
wird verwendet,
um die Biba-Richtlinie auf der pty(4)-Schnittstelle zu
deaktivieren.
security.mac.biba.revocation_enabled
erzwingt das Zurücksetzen des Labels, falls dieses zeitweise
geändert wurde um ein Subjekt zu dominieren.
Um Einstellungen der Biba Richtlinie für Systemobjekte zu
verändern werden die Befehle setfmac
und
getfmac
verwendet:
#
setfmac biba/low test
#
getfmac test
test: biba/lowIntegrität garantiert, im Unterschied zu Sensitivität, dass Informationen nur durch vertraute Parteien verändert werden können. Dies schließt Informationen ein, die zwischen Subjekten ausgetauscht werden, zwischen Objekt, oder auch zwischen den beiden. Durch Integrität wird gesichert, das Nutzer nur Informationen verändern, oder gar nur lesen können, die sie explizit benötigen.
Das Modul mac_biba(4) eröffnet einem Administrator die Möglichkeit zu bestimmen, welche Dateien oder Programme ein Nutzer oder eine Nutzergruppe sehen bzw. aufrufen darf. Gleichzeitig kann er zusichern, dass dieselben Programme und Dateien frei von Bedrohungen sind und das System die Echtheit gewährleistet - für diesen Nutzer oder die Nutzergruppe.
Während der anfänglichen Phase der Planung muß der
Administrator vorbereitet sein, Nutzer in Klassen, Stufen und Bereiche
einzuteilen. Der Zugriff auf Dateien und insbesondere auch Programme
wird verhindert sowohl vor als auch nachdem sie gestartet wurden. Das
System selbst erhält als Voreinstellung das Label
biba/high
sobald das Modul aktiviert wird - und
es liegt allein am Administrator, die verschiedenen Klassen und Stufen
für die einzelnen Nutzer zu konfigurieren. Anstatt mit Freigaben
zu arbeiten, wie weiter oben gezeigt wurde, könnte man auch
Überbegriffe für Projekte oder Systemkomponenten entwerfen.
Zum Beispiel, ausschließlich Entwicklern den Vollzugriff auf
Quellcode, Compiler und Entwicklungswerkzeuge gewähren,
während man andere Nutzer in Kategorien wie Tester, Designer oder
einfach nur „allgemeiner Nutzer“ zusammenfaßt, die
für diese Bereiche lediglich lesenden Zugriff erhalten
sollen.
Mit seinem ursprünglichen Sicherheits-Standpunkt ist ein Subjekt niedrigerer Integrität unfähig, ein Subjekt höherer Integrität zu verändern. Ein Subjekt höherer Integrität kann ein Subjekt niedrigerer Integrität weder beobachten noch lesen. Wenn man ein Label für die niedrigstmögliche Klasse erstellt, kann man diese allen Subjekten verwehren. Einige weitsichtig eingerichtete Umgebungen, die diese Richtlinie verwenden, sind eingeschränkte Webserver, Entwicklungs- oder Test-Rechner oder Quellcode-Sammlungen. Wenig sinnvoll ist diese Richtlinie auf einer Arbeitsstation, oder auf Rechnern die als Router oder Firewall verwendet werden.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.