MAC Label sind Sicherheitsmerkmale, die, wenn sie zum Einsatz kommen, allen Subjekten und Objekten im System zugeordnet werden.
Wenn ein Administrator ein solches Merkmal bzw. Attribut setzen will, muß er/sie verstehen können, was da genau passiert. Die Attribute, die im speziellen Fall zu vergeben sind, hängen vom geladenen Modul und den darin jeweils implementierten Richtlinien ab. Jedes dieser Richtlinienmodule setzt die Arbeit mit seinen entsprechenden Attributen in individueller Weise um. Falls der Nutzer nicht versteht, was er da konfiguriert, oder auch, was seine Konfiguration für Begleiterscheinungen mit sich bringt, ergibt sich meist als Resultat ein unerwartetes, ja sogar unerwünschtes Verhalten des gesamten Systems.
Ein Label, einem Objekt verliehen, wird verwendet, um anhand einer Richtlinie eine sicherheitsrelevante Entscheidung über Zugriffsrechte zu fällen. In einigen Richtlinien enthält bereits das Label selbst alle dafür nötigen Informationen. Andere Richtlinien verwenden diese Informationen, um zunächst ein komplexes Regelwerk abzuarbeiten.
Wenn man zum Beispiel einer Datei das Attribut
biba/low
zuordnet, wird dieses durch das Biba
Sicherheitsrichtlinienmodul, und zwar mit dem Wert „low“,
verarbeitet.
Einige der Richtlinienmodule, die die Möglichkeit zum Vergeben von Labels unter FreeBSD unterstützen, bieten drei vordefinierte Labels an. Dieses nennen sich „high“, „low“ und „equal“. Obwohl die verschiedenen Module die Zugriffskontrolle auf verschiedene Weisen regeln, kann man sich sicher sein, das das „low“-Label der untersten, unsichersten Einstellung entspricht, das „equal“-Label die Verwendung des Moduls für das jeweilige Objekt oder Subjekt deaktiviert - und das „high“-Label die höchstmögliche Einstellung erzwingt. Im Speziellen gilt diese Aussage für die Richtlinien(-module) MLS und Biba.
In den meisten Umgebungen, sogenannten Single Label Environments,
wird Objekten nur ein einzelnes Label zugewiesen. Dadurch wird nur ein
Regelsatz für die Zugriffskontrolle auf das gesamte System verwendet
- und das ist meistens auch tatsächlich ausreichend. Es gibt wenige
Fälle, in denen mehrere Labels auf Dateisystemobjekte oder -subjekte
verwendet werden. In einem solchen Fall muß das Dateisystem mit
der tunefs(8)-Option multilabel
angepaßt
werden, da single label
die Standardeinstellung
ist.
Bei der Verwendung von Biba oder MLS kann man numerische Labels vergeben, die genau das Level angeben, an welcher Stelle in der Hierarchie das Subjekt oder Objekt einzuordnen ist. Dieses numerische Level wird verwendet, um Informationen in verschiedene Gruppen aufzuteilen oder zu sortieren - damit zum Beispiel nur Subjekte, die zu einer gewissen Vertraulichkeitsstufe gehören, Zugang zu einer Gruppe von Objekten erhalten.
In den meisten Fällen wird ein Administrator nur ein einzelnes Label für das gesamte Dateisystem verwenden.
Moment mal, dass ist doch dasselbe wie
DAC! Ich dachte, MAC würde die
Kontrolle strengstens an den Administrator binden! Diese
Aussage hält immer noch stand - root
ist
derjenige, der die Kontrolle ausübt und die Richtlinie konfiguriert,
so dass Nutzer in die entsprechenden, angemessenen Kategorien /
Zugriffsklassen eingeordnet werden. Nunja, einige Module schränken
root
selbst ein. Die Kontrolle über Objekte
wird dann einer Gruppe zugewiesen, jedoch hat root
die Möglichkeit, die Einstellungen jederzeit zu widerrufen oder zu
ändern. Dies ist das Hierarchie/Freigabe-Modell, das durch
Richtlinien wie MLS oder Biba bereitgestellt wird.
Gewissermaßen alle Aspekte der Labelkonfiguration werden durch Werkzeuge das Basissystems umgesetzt. Die entsprechenden Kommandos bieten eine einfache Schnittstelle zum Konfigurieren, Manipulieren und auch Verifizieren der gekennzeichneten Objekte.
Mit den beiden Kommandos setfmac(8) und setpmac(8) kann
man eigentlich schon alles machen. Das Kommando
setfmac
wird verwendet, um ein MAC-Label auf einem
Systemobjekt zu setzen, setpmac
hingegen zum Setzen
von Labels auf Systemsubjekte. Als Beispiel soll hier dienen:
#
setfmac biba/high test
Wenn bei der Ausführung dieses Kommandos keine Fehler aufgetreten sind, gelangt man zur Eingabeaufforderung zurück. Nur wenn ein Fehler auftritt, verhalten sich diese Kommandos nicht still, ganz wie auch die Kommandos chmod(1) und chown(8). In einigen Fällen wird dieser Fehler Permission denied lauten und gewöhnlich dann auftreten, wenn ein Label an einem Objekt angebracht oder verändert werden soll, das bereits (Zugriffs-)Beschränkungen unterliegt.[11] Der Systemadministrator kann so eine Situation mit Hilfe der folgenden Kommandos überwinden:
#
setfmac biba/high test
Permission denied
#
setpmac biba/low setfmac biba/high test
#
getfmac test
test: biba/highWie wir hier sehen, kann setpmac
verwendet
werden, um die vorhandene Einstellungen zu umgehen, indem dem
gestarteten Prozeß ein anderes, valides Label zugeordnet wird.
Das Werkzeug getpmac
wird normalerweise auf gerade
laufende Prozesse angewendet. Ähnlich
sendmail: Als Argument wird statt eines
Kommandos eine eine Prozeß-ID übergeben, es verbirgt sich
doch dieselbe Logik dahinter. Wenn ein Nutzer versucht, eine Datei zu
verändern, auf die er keinen Zugriff hat, entsprechend der Regeln
eines geladenen Richtlinienmoduls, wird der Fehler Operation
not permitted durch die Funktion
mac_set_link
angezeigt.
Wenn man die Module mac_biba(4), mac_mls(4) und
mac_lomac(4) verwendet, hat man die Möglichkeit, einfache
Label zu vergeben. Diese nennen sich high
,
low
und equal
. Es folgt eine
kurze Beschreibung, was diese Labels bedeuten:
Das Label low
ist
definitionsgemäß das niedrigeste Label, das einem
Objekt oder Subjekt verliehen werden kann. Wird es gesetzt, kann
die entsprechende Entität nicht mehr auf Entitäten
zugreifen, die das Label high
tragen.
Das Label equal
wird Entitäten
verliehen, die von der Richtlinie ausgenommen sein sollen.
Das Label high
verleiht einer Entität
die höchstmögliche Einstellung.
Unter Beachtung jedes einzelnen Richtlinienmoduls moduliert und beschränkt jede dieser Einstellungen den Informationsfluß unterschiedlich. Genaue Erklärungen zu den Charakteristika der einfachen Labels in den verschiedenen Modulen finden sich im entsprechenden Unterabschnitt dieses Kapitels oder in den Manpages.
Numerische klassifizierte Labels werden verwendet in der Form
Klasse:Verbund+Verbund
. Demnach ist das
Label
folgendermaßen zu lesen:
„Biba Policy Label“/„effektive Klasse 10“ :„Verbund 2,3 und 6“: („Low-Klasse 5:...“- „High-Klasse 15:...“)
In diesem Beispiel ist die erstgenannte Klasse als „effektive Klasse“ zu bezeichnen. Ihr werden die „effektiven Verbünde“ zugeordnet. Die zweite Klasse ist die „Low“-Klasse und die letzte die „high“-Klasse. Die allermeisten Konfigurationen kommen ohne die Verwendungen von solchen Klassen aus, nichtsdestotrotz kann man sie für erweiterte Konfigurationen verwenden.
Sobald sie auf Systemsubjekte angewendet werden, haben diese eine gegenwärtige Klasse/Verbund- Konfiguration und diese muß im definierten Rahmen gegebenenfalls angepaßt (erhöht oder gesenkt) werden. Im Gegensatz dazu haben Systemobjekte alle eingestellten (effektive, High- und Low-Klasse) gleichzeitig. Dies ist notwendig, damit auf Sie von den Systemsubjekten in den verschiedenen Klassen gleichzeitig zugegriffen werden kann.
Die Klasse und und die Verbünde in einem Subjekt-Objekt-Paar
werden zum Erstellen einer sogenannten Dominanz-Relation verwendet,
in welcher entweder das Subjekt das Objekt, das Objekt das Subjekt,
keines das andere dominiert oder sich beide gegenseitig dominieren.
Der Fall, dass sich beide dominieren, tritt dann ein, wenn die beiden
Labels gleich sind. Wegen der Natur des Informationsflusses in Biba
kann man einem Nutzer Rechte für einen Reihe von Abteilungen
zuordnen, die zum Beispiel mit entsprechenden Projekten
korrespondieren. Genauso können aber auch Objekten mehrere
Abteilungen zugeordnet sein. Die Nutzer müssen eventuell ihre
gegenwärtigen Rechte mithilfe von su
or
setpmac
anpassen um auf Objekte in einer Abteilung
zuzugreifen, zu der sie laut ihrer effektiven Klasse nicht berechtigt
sind.
Nutzer selbst brauchen Labels damit ihre Dateien und Prozesse
korrekt mit der Sicherheitsrichtlinie zusammenarbeitet, die für
das System definiert wurde. Diese werden in der Datei
login.conf
durch die Verwendung von Login-
Klassen zugeordnet. Jedes Richtlinienmodul, das Label verwendet,
arbeitet mit diesen Login-Klassen.
Beispielhaft wird der folgende Eintrag, der für jede Richtlinie eine Einstellung enthält, gezeigt:
Die Label-Option in der letzten Zeile legt fest, welches Standard-Label für einen Nutzer erzwungen wird. Nutzern darf niemals gestattet werden, diese Werte selbst zu verändern, demnach haben Nutzer in dieser Beziehung auch keine Wahlfreiheit. In einer richtigen Konfiguration jedoch wird kein Administrator alle Richtlinienmodule aktivieren wollen. Es wird an dieser Stelle ausdrücklich empfohlen, dieses Kapitel zu Ende zu lesen, bevor irgendein Teil dieser Konfiguration ausprobiert wird.
Nutzer können ihr eigenes Label nach dem Loginvorgang
durchaus ändern. Jedoch kann diese Änderung nur unter den
Auflagen der gerade gültigen Richtlinie geschehen. Im
Beispiel oben wird für die Biba-Richtlinie eine minimale
Prozeßintegrität von 5, eine maximale von 15 angegeben,
aber die Voreinstellung des tatsächlichen Labels ist 10. Der
Nutzerprozeß läuft also mit einer Integrität von 10
bis das Label verändert wird, zum Beispiel durch eine
Anwendung des Kommandos setpmac
, welches jedoch
auf den Bereich eingeschränkt wird, der zum Zeitpunkt des
Logins angegeben wurde, in diesem Fall von 5 bis 15.
Nach einer Änderung der Datei
login.conf
muß in jedem Fall die
Befähigungsdatenbank mit dem Kommando
cap_mkdb
neu erstellt werden - und das gilt
für alle im weiteren Verlauf gezeigten Beispiele und
Diskussionspunkte.
Es ist nützlich anzumerken, dass viele Einsatzorte eine große Anzahl von Nutzern haben, die wiederum viele verschiedenen Nutzerklassen angehören sollen. Hier ist eine Menge Planungsarbeit notwendig, da die Verwaltung sehr unübersichtlich und schwierig ist.
Labels können auch, wenn man sie an Netzwerkschittstellen
vergibt, helfen, den Datenfluß durch das Netzwerk zu
kontrollieren. Das funktioniert in allen Fällen genau so wie mit
Objekten. Nutzer, die in der Biba-Richtlinie das Label
high
tragen, dürfen nicht auf Schnittstellen
zugreifen, die low
markiert sind usw.
Die Option maclabel
wird via
ifconfig
übergeben. Zum Beispiel
#
ifconfig bge0 maclabel biba/equal
belegt die Schnittstelle bge(4) mit dem
MAC Label biba/equal
. Wenn eine
komplexe Einstellung wie biba/high(low-high)
verwendet wird, muß das gesamte Label in Anführungszeichen
geschrieben werden, da sonst eine Fehlermeldung zurückgegeben
wird.
Jedes Richtlinienmodul, das die Vergabe von Labels
unterstützt, stellt einen Parameter bereit, mit dem das
MAC Label für Netzwerkschnittstellen
deaktiviert werden kann. Das Label der Netzwerkschnittstelle auf
equal
zu setzen, führt zum selben Ergebnis.
Beachten Sie die Ausgabe von sysctl
, die Manpages
der verschiedenen Richtlinien oder eben die Informationen, die im
weiteren Verlauf dieses Kapitels angeboten werden, um mehr zu diesen
Parametern zu erfahren.
Als Standardeinstellung verwendet das System die Option
single label
. Was bedeutet das für den
Administrator? Es gibt einige Unterschiede zwischen single
label
und multilabel
. In ihrer ureigenen
Weise bieten beide Vor- und Nachteile bezogen auf die Flexibilität
bei der Modellierung der Systemsicherheit.
Die Option single label
gibt jedem Subjekt oder
Objekt genau ein einziges Label, zum Beispiel
biba/high
. Mit dieser Option hat man einen
geringeren Verwaltungsaufwand, aber die Flexibilität beim
Einsatzes von Richtlinien ist ebenso gering. Viele Administratoren
wählen daher auch die Option multilabel
im
Sicherheitsmodell, wenn die Umstände es erfordern.
Die Option multilabel
gestattet, jedem einzelnen
Subjekt oder Objekt seine eigenen unabhängigen Label zu
zuzuordnen. Die Optionen multilabel
und
singlelabel
betreffen jedoch nur die Richtlinien, die Labels
als Leistungsmerkmal verwenden, einschließlich der Richtlinien
Biba, Lomac, MLS und
SEBSD.
Wenn Richtlinien benutzt werden sollen, die ohne Labels auskommen,
wird die Option multilabel
nicht benötigt. Dies
betrifft die Richtlinien seeotheruids
,
portacl
und partition
.
Man sollte sich dessen bewußt sein, dass die Verwendung der
Option multilabel
auf einer Partition und die
Erstellung eines Sicherheitsmodells auf der Basis der FreeBSD
multilevel
Funktionalität einen hohen
Verwaltungsaufwand bedeutet, da alles im Dateisystem ein Label bekommt.
Jedes Verzeichnis, jede Datei und genauso jede Schnittstelle.
Das folgende Kommando aktiviert multilabel
für ein Dateisystem. Dies funktioniert nur im
Einzelbenutzermodus:
#
tunefs -l enable /
In einer Swap-Partition wird dies nicht benötigt.
Falls Sie Probleme beim Setzen der Option
multilabel
auf der Root-Partition bemerken, lesen
Sie bitte Abschnitt 17.17, „Fehler im MAC beheben“ dieses Kapitels.
[11] Andere Vorbedingungen führen natürlich zu anderen Fehlern. Zum Beispiel wenn das Objekt nicht dem Nutzer gehört, der das Label ändern möchte, das Objekt vielleicht gar nicht existiert oder es sich um ein nur lesbares Objekt handelt. Oder eine verbindliche Richtlinie erlaubt dem Prozeß die Veränderung des Labels nicht, weil die Eigenschaften der Datei, die Eigenschaften des Prozesses oder der Inhalt des neuen Labels nicht akzeptiert werden. Beispiel: Ein Anwender mit geringer Vertraulichkeit versucht, das Label einer Datei mit hoher Vertraulichkeit zu ändern. Oder er versucht, eine Datei mit geringer Vertraulichkeit zu einer Datei mit hoher Vertraulichkeit zu machen.
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>.