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.[1] 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/high
Wie 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
biba/10:2+3+6(5:2+3-15:2+3+4+5+6)
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:
default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/usr/sbin/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :vmemoryuse=100M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=91d:\ :umask=022:\ :ignoretime@:\ :label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:
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.
Anmerkung: 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.
Anmerkung: Falls Sie Probleme beim Setzen der Option
multilabelauf der Root-Partition bemerken, lesen Sie bitte Abschnitt 17.17 dieses Kapitels.
| [1] |
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. |
| Zurück | Zum Anfang | Weiter |
| Erläuterung | Nach oben | Planung eines Sicherheitsmodells |
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>.