<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
<!--
The FreeBSD Documentation Project
The FreeBSD German Documentation Project
$FreeBSD$
$FreeBSDde: de-docproj/books/handbook/mac/chapter.sgml,v 1.8 2010/12/18 09:58:33 jkois Exp $
basiert auf: 1.80
-->
<chapter id="mac">
<chapterinfo>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>Written by </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Benjamin</firstname>
<surname>Lukas</surname>
<contrib>Übersetzt von </contrib>
</author>
</authorgroup>
</chapterinfo>
<title>Verbindliche Zugriffskontrolle</title>
<sect1 id="mac-synopsis">
<title>Übersicht</title>
<indexterm><primary>MAC</primary></indexterm>
<indexterm>
<primary>Mandatory Access Control</primary>
<see>MAC</see>
</indexterm>
<para> In &os; 5.X wurden neue Sicherheits-Erweiterungen
verfügbar, die aus dem TrustedBSD-Projekt übernommen wurden
und auf dem Entwurf &posix;.1e basieren. Die beiden
bedeutendsten neuen Sicherheits-Mechanismen sind Berechtigungslisten
(Access Control Lists, <acronym>ACL</acronym>) und die verbindliche
Zugriffskontrolle (Mandatory Access Control, <acronym>MAC</acronym>).
Durch die MAC können Module geladen werden, die neue
Sicherheitsrichtlinien bereitstellen. Mit Hilfe einiger Module kann
beispielsweise ein eng umgrenzter Bereich des Betriebssystems gesichert
werden, indem die Sicherheitsfunktionen spezieller Dienste
unterstützt bzw. verstärkt werden. Andere Module wiederum
betreffen in ihrer Funktion das gesamte System - alle vorhandenen
Subjekte und Objekte. Das "Verbindliche" in der Namensgebung
erwächst aus dem Fakt, dass die Kontrolle allein Administratoren
und dem System obliegt und nicht dem Ermessen der Nutzer, wie es mit
Hilfe der benutzerbestimmbaren Zugriffskontrolle (Discrectionary Access
Control / <acronym>DAC</acronym>), dem Zugriffstandard für Dateien,
gar der System V <acronym>IPC</acronym> in &os;, normalerweise umgesetzt
wird.</para>
<para>Dieses Kapitel wird sich auf die Grundstruktur der Verbindlichen
Zugriffskontrolle und eine Auswahl der Module, die verschiedenste
Sicherheitsfunktionen zur Verfügung stellen, konzentrieren.</para>
<para>Beim Durcharbeiten dieses Kapitels erfahren Sie:</para>
<itemizedlist>
<listitem>
<para>Welche <acronym>MAC</acronym> Module für
Sicherheitsrichtlinien derzeit in &os; eingebettet sind und wie die
entsprechenden Mechanismen funktionieren.</para>
</listitem>
<listitem>
<para>Was die einzelnen <acronym>MAC</acronym> Module an Funktionen
realisieren und auch, was der Unterschied zwischen einer Richtlinie,
die <emphasis>mit</emphasis> Labels arbeitet, und einer, die
<emphasis>ohne</emphasis> Labels arbeitet, ist.</para>
</listitem>
<listitem>
<para>Wie Sie die <acronym>MAC</acronym> in ein System einbetten und
effizient einrichten.</para>
</listitem>
<listitem>
<para>Wie die verschiedenen Richtlinienmodule einer MAC konfiguriert
werden.</para>
</listitem>
<listitem>
<para>Wie mit einer <acronym>MAC</acronym> und den gezeigten Beispielen
eine sicherere Umgebung erstellt werden kann.</para>
</listitem>
<listitem>
<para>Wie die Konfiguration einer <acronym>MAC</acronym> auf korrekte
Einrichtung getestet wird.</para>
</listitem>
</itemizedlist>
<para>Vor dem Lesen dieses Kapitels sollten Sie bereits:</para>
<itemizedlist>
<listitem>
<para>Grundzüge von &unix; und &os; verstanden haben.
(<xref linkend="basics"/>).</para>
</listitem>
<listitem>
<para>Mit den Grundzügen der Kernelkonfiguration und -kompilierung
vertraut sein (<xref linkend="kernelconfig"/>).</para>
</listitem>
<listitem>
<para>Einige Vorkenntnisse über Sicherheitskonzepte im Allgemeinen
und deren Umsetzung in &os; im Besonderen mitbringen (<xref
linkend="security"/>).</para>
</listitem>
</itemizedlist>
<warning>
<para>Der unsachgemäße Gebrauch der in diesem Kapitel
enthaltenen Informationen kann den Verlust des Systemzugriffs,
Ärger mit Nutzern oder die Unfähigkeit, grundlegende
Funktionen des X-Windows-Systems zu nutzen, verursachen. Wichtiger
noch ist, dass man sich nicht allein auf die <acronym>MAC</acronym>
verlassen sollte, um ein System zu sichern. Die <acronym>MAC</acronym>
verbessert und ergänzt lediglich die schon existierenden
Sicherheits-Richtlinien - ohne eine gründliche und fundierte
Sicherheitspraxis und regelmäßige Sicherheitsprüfungen
wird Ihr System nie vollständig sicher sein.</para>
<para>Außerdem sollte angemerkt werden, dass die Beispiele
in diesem Kapitel auch genau dasselbe sein sollen, nämlich
Beispiele. Es wird nicht empfohlen, diese bestimmten Beispiele
auf einem Arbeitssystem umzusetzen. Das Einarbeiten der
verschiedenen Sicherheitsmodule erfordert eine Menge Denkarbeit
und viele Tests. Jemand, der nicht versteht, wie diese Module
funktionieren, kann sich schnell darin wiederfinden, dass er
(oder sie) das ganze System durchforsten und viele Dateien und
Verzeichnisse neu konfigurieren muß.</para>
</warning>
<sect2>
<title>Was in diesem Kapitel nicht behandelt wird</title>
<para>Dieses Kapitel behandelt einen großen Teil
sicherheitsrelevanter Themen, bezogen auf die Verbindliche
Zugriffskontrolle (<acronym>MAC</acronym>). Die gegenwärtige
Entwicklung neuer <acronym>MAC</acronym> Module ist nicht
abgedeckt. Einige weitere Module, die im MAC Framework enthalten sind,
haben besondere Charakteristika, die zum Testen und Entwickeln neuer
Module gedacht sind. Dies sind unter anderem &man.mac.test.4;,
&man.mac.stub.4; und &man.mac.none.4;. Für weitere Informationen
zu diesen Modulen und den entsprechend angebotenen Funktionen lesen Sie
bitte die Manpages.</para>
</sect2>
</sect1>
<sect1 id="mac-inline-glossary">
<title>Schlüsselbegriffe</title>
<para>Bevor Sie weiterlesen, müssen noch einige Schlüsselbegriffe
geklärt werden. Dadurch soll jegliche auftretende Verwirrung von
vornherein beseitigt und die plötzliche Einführung neuer
Begriffe und Informationen vermieden werden.</para>
<itemizedlist>
<listitem>
<para><emphasis>Verbund</emphasis>: Ein Verbund ist ist ein Satz von
Programmen und Daten, die speziell und zusammen abgeschottet wurden,
um Nutzern Zugriff auf diese ausgewiesenen Systembereiche zu
gewähren. Man kann sagen, ein solcher Verbund ist eine
Gruppierung, ähnlich einer Arbeitsgruppe, einer Abteilung, einem
Projekt oder einem Thema. Durch die Nutzung von Verbünden
(<emphasis>compartments</emphasis>) kann man Sicherheitsrichtlinien
erstellen, die alles notwendige Wissen und alle Werkzeuge
zusammenfassen.</para>
</listitem>
<listitem>
<para><emphasis>Hochwassermarkierung</emphasis>: Eine solche Richtlinie
erlaubt die Erhöhung der Sicherheitsstufe in Abhängigkeit
der Klassifikation der gesuchten bzw. bereitzustellenden Information.
Normalerweise wird nach Abschluss des Prozesses die
ursprüngliche Sicherheitsstufe wieder hergestellt. Derzeit
enthält die <acronym>MAC</acronym> Grundstruktur keine
Möglichkeit, eine solche Richtlinie umzusetzen, der
Vollständigkeit halber ist die Definition hier jedoch
aufgeführt.</para>
</listitem>
<listitem>
<para><emphasis>Integrität</emphasis>: Das Schlüsselkonzept
zur Klassifizierung der Vertraulichkeit von Daten nennt man
Integrität. Je weiter die Integrität erhöht wird, umso
mehr kann man den entsprechenden Daten vertrauen.</para>
</listitem>
<listitem>
<para><emphasis>Label</emphasis>: Ein Label ist ein Sicherheitsmerkmal,
welches mit Dateien, Verzeichnissen oder anderen Elementen im System
verbunden wird. Man sollte es wie einen Vertraulichkeitsstempel
auffassen, der Dateien angehört wie beispielsweise die
Zugriffszeit, das Erstellungsdatum oder auch der Name; sobald Dateien
derart gekennzeichnet werden, bezeichnen diese Label die
sicherheitsrelevanten Eigenschaften. Zugriff ist nur noch dann
möglich, wenn das zugreifende Subjekt eine korrespondierende
Kennzeichnung trägt. Die Bedeutung und Verarbeitung der
Label-Werte ist von der Einrichtung der Richtlinie abhängig:
Während einige Richtlinien das Label zum Kennzeichnen der
Vertraulichkeit oder Geheimhaltungsstufe eines Objekts nutzen,
können andere Richtlinien an derselben Stelle Zugriffsregeln
festschreiben.</para>
</listitem>
<listitem>
<para><emphasis>Level</emphasis>: Eine erhöhte oder verminderte
Einstellung eines Sicherheitsmerkmals. Wenn das Level erhöht
wird, wird auch die ensprechende Sicherheitsstufe angehoben.</para>
</listitem>
<listitem>
<para><emphasis>Niedrigwassermarkierung</emphasis>: Eine solche
Richtlinie erlaubt das Herabstufen des Sicherheitslevels, um weniger
sensible Daten verfügbar zu machen. In die meisten Fällen
wird das ursprüngliche Sicherheitslevel des Nutzers
wiederhergestellt, sobald der Vorgang abgeschlossen ist. Das einzige
Modul in &os;, welches von dieser Richtlinie Gebrauch macht, ist
&man.mac.lomac.4;.</para>
</listitem>
<listitem>
<para><emphasis>Multilabel</emphasis>: Die Eigenschaft
<option>multilabel</option> ist eine Dateisystemoption, die entweder
im Einzelbenutzermodus mit Hilfe des Werkzeugs &man.tunefs.8;,
während des Bootvorgangs in der Datei &man.fstab.5; oder aber
beim Erstellen einen neues Dateisystems aktiviert werden kann. Diese
Option erlaubt einem Administrator, verschiedenen Objekten
unterschiedliche Labels zuzuordnen - kann jedoch nur zusammen mit
Modulen angewendet werden, die auch tatsächlich mit Labels
arbeiten.</para>
</listitem>
<listitem>
<para><emphasis>Objekt</emphasis>: Ein Objekt oder auch Systemobjekt
ist theoretisch eine Einheit, durch welche Information fließt,
und zwar unter der Lenkung eines <emphasis>Subjektes</emphasis>.
Praktisch schliesst diese Definition Verzeichnisse, Dateien, Felder,
Bildschirme, Tastaturen, Speicher, Bandlaufwerke, Drucker und
jegliche anderen Datenspeicher- oder -verarbeitungsgeräte ein.
Im Prinzip ist ein Objekt ein Datenkontainer oder eine
Systemressource - Zugriff auf ein <emphasis>Objekt</emphasis>
bedeutet, auf Daten zuzugreifen.</para>
</listitem>
<listitem>
<para><emphasis>Richtlinie</emphasis>: Eine Sammlung von Regeln, die
definiert, wie Zielvorgaben umgesetzt werden, nennt man Richtlinie.
Eine <emphasis>Richtlinie</emphasis> dokumentiert normalerweise, wie
mit bestimmten Elementen umgegangen wird. Dieses Kapitel faßt
den Begriff in diesem Kontext als
<emphasis>Sicherheitsrichtlinie</emphasis> auf; als eine Sammlung von
Regeln, die den Fluß von Daten und Informationen kontrolliert
und die gleichzeitig definiert, wer auf diese Daten und Informationen
zugreifen darf.</para>
</listitem>
<listitem>
<para><emphasis>Anfälligkeit</emphasis>: Dieser Begriff wird
normalerweise verwendet, wenn man über <acronym>MLS</acronym>
(Multi Level Security) spricht. Das Anfälligkeits-Level
beschreibt, wie wichtig oder geheim die Daten sein sollen. Um so
höher das Anfälligkeits-Level, um so wichtiger die
Geheimhaltung bzw. Vertraulichkeit der Daten.</para>
</listitem>
<listitem>
<para><emphasis>Einzel-Label</emphasis>: Von einem Einzel-Label spricht
man, wenn für ein ganzes Dateisystem lediglich ein einziges
Label verwendet wird, um Zugriffskontrolle über den gesamten
Datenfluss zu erzwingen. Sobald diese Option verwendet wird - und das
ist zu jeder Zeit, wenn die Option <option>multilabel</option>
nicht explizit gesetzt wurde - sind alle Dateien und Verzeichnisse
mit dem gleichen Label gekennzeichnet.</para>
</listitem>
<listitem>
<para><emphasis>Subjekt</emphasis>: Ein Subjekt ist jedwede Einheit,
die Information in Fluss zwischen Objekten bringt: Zum Beispiel ein
Nutzer, ein Nutzerprozessor, ein Systemprozeß usw. In &os;
handelt es sich meistens um einen Thread, der als Prozeß im
Namen eines Nutzers arbeitet.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="mac-initial">
<title>Erläuterung</title>
<para>Mit all diesen neuen Begriffen im Kopf können wir nun
überlegen, wie die Möglichkeiten der verbindlichen
Zugriffskontrolle (<acronym>MAC</acronym>) die Sicherheit eines
Betriebssystems als Ganzes erweitern. Die verschiedenen Module, die
durch die <acronym>MAC</acronym> bereitgestellt werden, können
verwendet werden, um das Netzwerk oder Dateisysteme zu schützen,
Nutzern den Zugang zu bestimmten Ports oder Sockets zu verbieten und
vieles mehr. Die vielleicht beste Weise, die Module zu verwenden, ist,
sie miteinander zu kombinieren, indem mehrere
Sicherheitsrichtlinienmodule gleichzeitig eine mehrschichtige
Sicherheitsumgebung schaffen. Das ist etwas anderes als singuläre
Richtlinien wie zum Beispiel die Firewall, die typischerweise Elemente
eines Systems stabilisiert, das nur für einen speziellen Zweck
verwendet wird. Der Verwaltungsmehraufwand ist jedoch von Nachteil, zum
Beispiel durch die Verwendung von mehreren Labels oder dem
eigenhändigen Erlauben von Netzwerkzugriffen für jeden
einzelnen Nutzer.</para>
<para>Solche Nachteile sind allerdings gering im Vergleich zum bleibenden
Effekt der erstellten Struktur. Die Möglichkeit zum Beispiel,
für konkrete Anwendungen genau die passenden Richtlinien
auszuwählen und einzurichten, senkt gleichzeitig die Arbeitskosten.
Wenn man unnötige Richtlinien aussortiert, kann man die
Gesamtleistung des Systems genauso steigern wie auch eine höhere
Anpassungsfähigkeit gewährleisten. Eine gute Umsetzung der
<acronym>MAC</acronym> beinhaltet eine Prüfung der gesamten
Sicherheitsanforderungen und einen wirksamen Einsatz der verschiedenen
Module.</para>
<para>Ein System, auf dem eine <acronym>MAC</acronym> verwendet wird,
muß zumindest garantieren, dass einem Nutzer nicht gestattet wird,
Sicherheitsmerkmale nach eigenem Ermessen zu verändern; dass
Arbeitswerkzeuge, Programme und Skripte, innerhalb der
Beschränkungen arbeiten können, welche die Zugriffsregeln der
ausgewählten Module dem System auferlegen; und dass die volle
Kontrolle über die Regeln der <acronym>MAC</acronym> beim
Administrator ist und bleibt.</para>
<para>Es ist die einsame Pflicht des zuständigen Administrators, die
richtigen Module sorgfältig auszuwählen. Einige Umgebungen
könnten eine Beschränkung der Zugriffe über die
Netzwerkschnittstellen benötigen - hier wären die Module
&man.mac.portacl.4;, &man.mac.ifoff.4; und sogar &man.mac.biba.4; ein
guter Anfang. In anderen Fällen muß man sehr strenge
Vertraulichkeit von Dateisystemobjekten gewährleisten - dafür
könnte man &man.mac.bsdextended.4; oder &man.mac.mls.4;
einsetzen.</para>
<para>Die Entscheidung, welche Richtlinien angewandt werden, kann auch
anhand der Netzwerk-Konfiguration getroffen werden. Nur bestimmten
Benutzern soll erlaubt werden, via &man.ssh.1; auf das Netzwerk oder
Internet zuzugreifen - &man.mac.portacl.4; wäre eine gute Wahl.
Aber für was entscheidet man sich im Falle eines Dateisystems?
Soll der Zugriff auf bestimmte Verzeichnisse von spezifischen Nutzern
oder Nutzergruppen separiert werden? Oder wollen wir den Zugriff durch
Nutzer oder Programme auf spezielle Dateien einschränken, indem wir
gewisse Objekte als geheim einstufen?</para>
<para>Der Zugriff auf Objekte kann einigen vertraulichen Nutzern gestattet
werden, anderen wiederum verwehrt. Als Beispiel sei hierzu ein
großes Entwicklerteam angeführt, das in kleine Gruppen von
Mitarbeitern aufgeteilt wurde. Die Entwickler von Projekt A dürfen
nicht auf Objekte zugreifen, die von den Entwicklern von Projekt B
geschrieben wurden. Sie müssen aber trotzdem auf Objekte
zugreifen können, die von einem dritten Entwicklerteam geschaffen
wurden - alles in allem eine verzwickte Situation. Wenn man die
verschiedenen Module der <acronym>MAC</acronym> richtig verwendet,
können Anwender in solche Gruppen getrennt und ihnen der Zugriff zu
den gewünschten Systemobjekten gestattet werden - ohne Angst haben
zu müssen, dass Informationen in die falschen Hände
geraten.</para>
<para>So hat jedes Modul, das eine Sicherheitsrichtlinie verfügbar
macht, einen eigenen Weg, die Sicherheit des Systems zu verstärken.
Die Auswahl der Module sollte auf einem gut durchdachten
Sicherheitskonzept gründen. In vielen Fällen muß das
gesamte Konzept eines Systems überarbeitet und neu eingepflegt
werden. Ein guter Überblick über die Möglichkeiten der
verschiedenen von der <acronym>MAC</acronym> angebotenen Module
hilft einem Administrator, die besten Richtlinien für seine
spezielle Situation auszuwählen.</para>
<para>Im &os;-Standardkernel ist die Option zur Verwendung der
<acronym>MAC</acronym> nicht enthalten. Daher muß die
Zeile</para>
<programlisting>options MAC</programlisting>
<para>der Kernelkonfiguration hinzugefügt und der Kernel neu
übersetzt und installiert werden.</para>
<caution>
<para>Verschiedenen Anleitungen für die <acronym>MAC</acronym>
empfehlen, die einzelnen Module direkt in den Kernel einzuarbeiten.
Dabei ist es jedoch möglich, das System aus dem Netzwerk
auszusperren oder gar schlimmeres. Die Arbeit mit der
<acronym>MAC</acronym> ist ähnlich der Arbeit mit einer Firewall -
man muß, wenn man sich nicht selbst aus dem System aussperren
will, genau aufpassen. Man sollte sich eine Möglichkeit
zurechtlegen, wie man eine Implementation einer <acronym>MAC</acronym>
rückgängig machen kann - genauso wie eine Ferninstallation
über das Netzwerk nur mit äußerster Vorsicht
vorgenommen werden sollte. Es wird daher empfohlen,
die Module nicht in den Kernel einzubinden, sondern sie beim
Systemstart via <filename>/boot/loader.conf</filename> zu
laden.</para>
</caution>
</sect1>
<sect1 id="mac-understandlabel">
<title>MAC Labels verstehen</title>
<para>MAC Label sind Sicherheitsmerkmale, die, wenn sie zum Einsatz kommen,
allen Subjekten und Objekten im System zugeordnet werden.</para>
<para>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.</para>
<para>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.</para>
<para>Wenn man zum Beispiel einer Datei das Attribut
<literal>biba/low</literal> zuordnet, wird dieses durch das Biba
Sicherheitsrichtlinienmodul, und zwar mit dem Wert <quote>low</quote>,
verarbeitet.</para>
<para>Einige der Richtlinienmodule, die die Möglichkeit zum Vergeben
von Labels unter &os; unterstützen, bieten drei vordefinierte
Labels an. Dieses nennen sich <quote>high</quote>, <quote>low</quote>
und <quote>equal</quote>. Obwohl die verschiedenen Module die
Zugriffskontrolle auf verschiedene Weisen regeln, kann man sich sicher
sein, das das <quote>low</quote>-Label der untersten, unsichersten
Einstellung entspricht, das <quote>equal</quote>-Label die Verwendung des
Moduls für das jeweilige Objekt oder Subjekt deaktiviert - und das
<quote>high</quote>-Label die höchstmögliche Einstellung
erzwingt. Im Speziellen gilt diese Aussage für die
Richtlinien(-module) <acronym>MLS</acronym> und Biba.</para>
<para>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 &man.tunefs.8;-Option <option>multilabel</option> angepaßt
werden, da <option>single label</option> die Standardeinstellung
ist.</para>
<para>Bei der Verwendung von Biba oder <acronym>MLS</acronym> 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.</para>
<para>In den meisten Fällen wird ein Administrator nur ein einzelnes
Label für das gesamte Dateisystem verwenden.</para>
<para><emphasis>Moment mal, dass ist doch dasselbe wie
<acronym>DAC</acronym>! Ich dachte, <acronym>MAC</acronym> würde die
Kontrolle strengstens an den Administrator binden!</emphasis> Diese
Aussage hält immer noch stand - <username>root</username> 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
<username>root</username> selbst ein. Die Kontrolle über Objekte
wird dann einer Gruppe zugewiesen, jedoch hat <username>root</username>
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.</para>
<sect2>
<title>Konfigurieren der Labels</title>
<para>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.</para>
<para>Mit den beiden Kommandos &man.setfmac.8; und &man.setpmac.8; kann
man eigentlich schon alles machen. Das Kommando
<command>setfmac</command> wird verwendet, um ein MAC-Label auf einem
Systemobjekt zu setzen, <command>setpmac</command> hingegen zum Setzen
von Labels auf Systemsubjekte. Als Beispiel soll hier dienen:</para>
<screen>&prompt.root; <userinput>setfmac biba/high test</userinput></screen>
<para>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 &man.chmod.1; und &man.chown.8;. In
einigen Fällen wird dieser Fehler <errorname>Permission
denied</errorname> lauten und gewöhnlich dann auftreten, wenn ein
Label an einem Objekt angebracht oder verändert werden soll, das
bereits (Zugriffs-)Beschränkungen
unterliegt.<footnote><para>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.</para></footnote> Der Systemadministrator kann so eine
Situation mit Hilfe der folgenden Kommandos überwinden:</para>
<screen>&prompt.root; <userinput>setfmac biba/high test</userinput>
<errorname>Permission denied</errorname>
&prompt.root; <userinput>setpmac biba/low setfmac biba/high test</userinput>
&prompt.root; <userinput>getfmac test</userinput>
test: biba/high</screen>
<para>Wie wir hier sehen, kann <command>setpmac</command> verwendet
werden, um die vorhandene Einstellungen zu umgehen, indem dem
gestarteten Prozeß ein anderes, valides Label zugeordnet wird.
Das Werkzeug <command>getpmac</command> wird normalerweise auf gerade
laufende Prozesse angewendet. Ähnlich
<application>sendmail</application>: 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 <errorname>Operation
not permitted</errorname> durch die Funktion
<function>mac_set_link</function> angezeigt.</para>
<sect3>
<title>Übliche Typen von Labeln</title>
<para>Wenn man die Module &man.mac.biba.4;, &man.mac.mls.4; und
&man.mac.lomac.4; verwendet, hat man die Möglichkeit, einfache
Label zu vergeben. Diese nennen sich <literal>high</literal>,
<literal>low</literal> und <literal>equal</literal>. Es folgt eine
kurze Beschreibung, was diese Labels bedeuten:</para>
<itemizedlist>
<listitem>
<para>Das Label <literal>low</literal> 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 <literal>high</literal> tragen.</para>
</listitem>
<listitem>
<para>Das Label <literal>equal</literal> wird Entitäten
verliehen, die von der Richtlinie ausgenommen sein sollen.</para>
</listitem>
<listitem>
<para>Das Label <literal>high</literal> verleiht einer Entität
die höchstmögliche Einstellung.</para>
</listitem>
</itemizedlist>
<para>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.</para>
<sect4>
<title>Fortgeschrittene Label-Konfiguration</title>
<para>Numerische klassifizierte Labels werden verwendet in der Form
<literal>Klasse:Verbund+Verbund</literal>. Demnach ist das
Label</para>
<programlisting>biba/10:2+3+6(5:2+3-15:2+3+4+5+6)</programlisting>
<para>folgendermaßen zu lesen:</para>
<para><quote>Biba Policy Label</quote>/<quote>effektive Klasse
10</quote>
:<quote>Verbund 2,3 und 6</quote>:
(<quote>Low-Klasse 5:...</quote>-
<quote>High-Klasse 15:...</quote>)</para>
<para>In diesem Beispiel ist die erstgenannte Klasse als
<quote>effektive Klasse</quote> zu bezeichnen. Ihr werden die
<quote>effektiven Verbünde</quote> zugeordnet. Die zweite
Klasse ist die <quote>Low</quote>-Klasse und die letzte die
<quote>high</quote>-Klasse. Die allermeisten Konfigurationen kommen
ohne die Verwendungen von solchen Klassen aus, nichtsdestotrotz kann
man sie für erweiterte Konfigurationen verwenden.</para>
<para>Sobald sie auf <emphasis>Systemsubjekte</emphasis> 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 <emphasis>Systemobjekte</emphasis> alle
eingestellten (effektive, High- und Low-Klasse) gleichzeitig. Dies
ist notwendig, damit auf Sie von den
<emphasis>Systemsubjekten</emphasis> in den verschiedenen Klassen
gleichzeitig zugegriffen werden kann.</para>
<para>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 <command>su</command> or
<command>setpmac</command> anpassen um auf Objekte in einer Abteilung
zuzugreifen, zu der sie laut ihrer effektiven Klasse nicht berechtigt
sind.</para>
</sect4>
</sect3>
<sect3>
<title>Nutzer- und Label-Einstellungen</title>
<para>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
<filename>login.conf</filename> durch die Verwendung von Login-
Klassen zugeordnet. Jedes Richtlinienmodul, das Label verwendet,
arbeitet mit diesen Login-Klassen.</para>
<para>Beispielhaft wird der folgende Eintrag, der für jede
Richtlinie eine Einstellung enthält, gezeigt:</para>
<programlisting>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]:</programlisting>
<para>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.</para>
<note>
<para>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 <command>setpmac</command>, welches jedoch
auf den Bereich eingeschränkt wird, der zum Zeitpunkt des
Logins angegeben wurde, in diesem Fall von 5 bis 15.</para>
</note>
<para>Nach einer Änderung der Datei
<filename>login.conf</filename> muß in jedem Fall die
Befähigungsdatenbank mit dem Kommando
<command>cap_mkdb</command> neu erstellt werden - und das gilt
für alle im weiteren Verlauf gezeigten Beispiele und
Diskussionspunkte.</para>
<para>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.</para>
</sect3>
<sect3>
<title>Netzwerkschnittstellen und die zugehörigen Label</title>
<para>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
<literal>high</literal> tragen, dürfen nicht auf Schnittstellen
zugreifen, die <literal>low</literal> markiert sind usw.</para>
<para>Die Option <option>maclabel</option> wird via
<command>ifconfig</command> übergeben. Zum Beispiel</para>
<screen>&prompt.root; <userinput>ifconfig bge0 maclabel biba/equal</userinput></screen>
<para>belegt die Schnittstelle &man.bge.4; mit dem
<acronym>MAC</acronym> Label <literal>biba/equal</literal>. Wenn eine
komplexe Einstellung wie <literal>biba/high(low-high)</literal>
verwendet wird, muß das gesamte Label in Anführungszeichen
geschrieben werden, da sonst eine Fehlermeldung zurückgegeben
wird.</para>
<para>Jedes Richtlinienmodul, das die Vergabe von Labels
unterstützt, stellt einen Parameter bereit, mit dem das
<acronym>MAC</acronym> Label für Netzwerkschnittstellen
deaktiviert werden kann. Das Label der Netzwerkschnittstelle auf
<literal>equal</literal> zu setzen, führt zum selben Ergebnis.
Beachten Sie die Ausgabe von <command>sysctl</command>, die Manpages
der verschiedenen Richtlinien oder eben die Informationen, die im
weiteren Verlauf dieses Kapitels angeboten werden, um mehr zu diesen
Parametern zu erfahren.</para>
</sect3>
</sect2>
<sect2>
<title>Single- oder Multilabel?</title>
<para>Als Standardeinstellung verwendet das System die Option
<option>single label</option>. Was bedeutet das für den
Administrator? Es gibt einige Unterschiede zwischen <option>single
label</option> und <option>multilabel</option>. In ihrer ureigenen
Weise bieten beide Vor- und Nachteile bezogen auf die Flexibilität
bei der Modellierung der Systemsicherheit.</para>
<para>Die Option <option>single label</option> gibt jedem Subjekt oder
Objekt genau ein einziges Label, zum Beispiel
<literal>biba/high</literal>. 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 <option>multilabel</option> im
Sicherheitsmodell, wenn die Umstände es erfordern.</para>
<para>Die Option <option>multilabel</option> gestattet, jedem einzelnen
Subjekt oder Objekt seine eigenen unabhängigen Label zu
zuzuordnen. Die Optionen <option>multilabel</option> und <option>
singlelabel</option> betreffen jedoch nur die Richtlinien, die Labels
als Leistungsmerkmal verwenden, einschließlich der Richtlinien
Biba, Lomac, <acronym>MLS</acronym> und
<acronym>SEBSD</acronym>.</para>
<!-- ================================================================================== --
-- ================================================================================== --
-- ================================================================================== --
-- Das folgende Beispiel weigere ich mich zu uebersetzen. Der Autor selbst schreibt --
-- schreibt ja, dass es only a quick example ist. --
-- <para>In many cases, the <option>multilabel</ option> may not need --
-- to be set at all. Consider the following situation and --
-- security model:</para> --
-- <itemizedlist> --
-- <listitem> --
-- <para>&os; web-server using the <acronym>MAC</acronym> --
-- framework and a mix of the various policies.</para> --
-- </listitem> --
-- <listitem> --
-- <para>This machine only requires one label, --
-- <literal>biba/high</literal>, for everything in the system. --
-- Here the file system would not require the --
-- <option>multilabel</ option> option as a single label --
-- will always be in effect.</para> --
-- </listitem> --
-- <listitem> --
-- <para>But, this machine will be a web server and should have --
-- the web server run at <literal>biba/low</literal> to prevent --
-- write up capabilities. The Biba policy and how it works --
-- will be discussed later, so if the previous comment was --
-- difficult to interpret just continue reading and return. --
-- The server could use a separate partition set at --
-- <literal>biba/low</literal> for most if not all of its --
-- runtime state. Much is lacking from this example, for --
-- instance the restrictions on data, configuration and user --
-- settings; however, this is just a quick example to prove the --
-- aforementioned point.</para> --
-- </listitem> --
-- </itemizedlist> --
-- end of quick example --
-- ================================================================================== --
-- ================================================================================== --
-- ================================================================================== -->
<para>Wenn Richtlinien benutzt werden sollen, die ohne Labels auskommen,
wird die Option <option>multilabel</option> nicht benötigt. Dies
betrifft die Richtlinien <literal>seeotheruids</literal>,
<literal>portacl</literal> und <literal>partition</literal>.</para>
<para>Man sollte sich dessen bewußt sein, dass die Verwendung der
Option <option>multilabel</option> auf einer Partition und die
Erstellung eines Sicherheitsmodells auf der Basis der &os;
<option>multilevel</option> Funktionalität einen hohen
Verwaltungsaufwand bedeutet, da alles im Dateisystem ein Label bekommt.
Jedes Verzeichnis, jede Datei und genauso jede Schnittstelle.</para>
<para>Das folgende Kommando aktiviert <option>multilabel</option>
für ein Dateisystem. Dies funktioniert nur im
Einzelbenutzermodus:</para>
<screen>&prompt.root; <userinput>tunefs -l enable /</userinput></screen>
<para>In einer Swap-Partition wird dies nicht benötigt.</para>
<note>
<para>Falls Sie Probleme beim Setzen der Option
<option>multilabel</option> auf der Root-Partition bemerken, lesen
Sie bitte <xref linkend="mac-troubleshoot"/> dieses Kapitels.</para>
</note>
</sect2>
</sect1>
<sect1 id="mac-planning">
<title>Planung eines Sicherheitsmodells</title>
<para>Wann immer eine neue Technologie eingepflegt werden soll, ist es
wichtig, vorher einen Plan zu erstellen. In den verschiedenen Etappen
der Planung sollte der Administrator nie das
<quote>Große Ganze</quote> aus den Augen verlieren und mindestens
die folgenden Punkte beachten:</para>
<itemizedlist>
<listitem>
<para>Die Anforderungen</para>
</listitem>
<listitem>
<para>Die Ziele</para>
</listitem>
</itemizedlist>
<para>Wenn Sie <acronym>MAC</acronym> verwenden möchten, sind das im
Besonderen folgende Punkte:</para>
<itemizedlist>
<listitem>
<para>Wie werden Informationen und Ressourcen auf den Zielsystemen
klassifiziert?</para>
</listitem>
<listitem>
<para>Welche Arten von Informationen bzw. Ressourcen sollen im Zugang
beschränkt sein und welche Art Einschränkung soll
verwendet werden?</para>
</listitem>
<listitem>
<para>Welche(s) <acronym>MAC</acronym> Modul(e) wählt man, um sein
Ziel zu erreichen?</para>
</listitem>
</itemizedlist>
<para>Es ist immer möglich, die Einstellungen des Systems und der
Systemressourcen im Nachhinein zu <quote>optimieren</quote>. Es ist aber
wirklich lästig, das gesamte Dateisystem zu durchsuchen, um Dateien
oder Benutzerkonten zu reparieren. Eine gute Planung hilft dem
Administrator, sich einer sorgenfreien und effizienten Umsetzung eines
Sicherheitsmodells zu versichern. Testlauf des Sicherheitsmodells
<emphasis>vor</emphasis> dem Einsatz in seiner richtigen Arbeitsumgebung
ist auf jeden Fall empfehlenswert. Die Idee, ein System mit einer
<acronym>MAC</acronym> einfach loslaufen zu lassen, ist wie direkt auf
einen Fehlschlag hinzuarbeiten.</para>
<para>Jede Umgebung hat ihre eigenen Anforderungen. Ein tiefgreifendes und
vollständiges Sicherheitsprofil zu erstellen spart weitere
Änderungen, nachdem das System in Betrieb genommen wurde. Also
werden die folgenden Abschnitte die verschiedenen Module vorstellen, die
den Administratoren zur Verfügung gestellt werden, die Nutzung und
Konfiguration der einzelnen Module beschreiben; und in einigen
Fällen Einblicke gewähren, für welche Situationen welche
Module besonders geeignet sind. Zum Beispiel ein Webserver kann von der
Verwendung der &man.mac.biba.4; oder der &man.mac.bsdextended.4;
Richtlinie profitieren. In anderen Fällen, an einem Rechner mit nur
wenigen lokalen Benutzern, ist die &man.mac.partition.4; die Richtlinie
der Wahl.</para>
</sect1>
<sect1 id="mac-modules">
<title>Modulkonfiguration</title>
<para>Jedes Modul, das in der <acronym>MAC</acronym> enthalten ist, kann
entweder direkt in den Kernel eingefügt werden oder als Kernelmodul
in der Laufzeit des Systems geladen werden. Empfohlen wird, den
Modulnamen in der Datei <filename>/boot/loader.conf</filename>
anzufügen, so dass das Modul am Anfang des Bootvorgangs eingebunden
wird.</para>
<para>Die folgenden Abschnitte werden verschiedene <acronym>MAC</acronym>
Module und ihre jeweiligen Vor- und Nachteile vorstellen. Außerdem
wird erklärt, wie sie in bestimmte Umgebungen eingearbeitet werden
können. Einige Module unterstützen die Verwendung von
<literal>Labels</literal>, das heißt Zugriffskontrolle durch
hinzufügen einer Kennzeichnung in der Art von <quote>dieses ist
erlaubt, jenes aber nicht</quote>. Eine Label-Konfigurationdatei
kontrolliert unter anderem, wie auf Dateien zugegriffen oder wie
über das Netzwerk kommuniziert werden darf. Im vorangehenden
Abschnitt wurde bereits erläutert, wie die Option
<option>multilabel</option> auf Dateisysteme angewendet wird, um eine
Zugriffskontrolle auf einzelne Dateien oder ganze Dateisysteme zu
konfigurieren.</para>
<para>Eine <option>single label</option> Konfiguration erzwingt ein
einzelnes Label für das gesamte System. Daher wird die
<command>tunefs</command>-Option <option>multilabel</option> genannt.
</para>
</sect1>
<sect1 id="mac-seeotheruids">
<title>Das MAC Modul seeotheruids</title>
<indexterm>
<primary>MAC See Other UIDs Policy</primary>
</indexterm>
<para>Modulename: <filename>mac_seeotheruids.ko</filename></para>
<para>Parameter in der Kernelkonfiguration:
<literal>options MAC_SEEOTHERUIDS</literal></para>
<para>Bootparameter:
<literal>mac_seeotheruids_load="YES"</literal></para>
<para>Das Modul &man.mac.seeotheruids.4; erweitert die
<command>sysctl</command>-Variablen
<literal>security.bsd.see_other_uids</literal> und
<literal>security.bsd.see_other_gids</literal>. Diese Optionen
benötigen keine im Vorhinein zu setzenden Labels und können
leicht durchschaubar mit den anderen MAC-Modulen zusammenarbeiten.</para>
<para>Nachdem das Modul geladen wurde, können die folgenden
<command>sysctl</command> Variablen verwendet werden.</para>
<itemizedlist>
<listitem>
<para><literal>security.mac.seeotheruids.enabled</literal> dient zur
Aktivierung des Moduls, zunächst mit den Standardeinstellungen.
Diese verhindern, dass Nutzer Prozesse und Sockets sehen können,
die ihnen nicht selbst gehöen.</para>
</listitem>
<listitem>
<para>
<literal>security.mac.seeotheruids.specificgid_enabled</literal> kann
eine spezifizierte Nutzergruppe von dieser Richtlinie ausnehmen. Die
entsprechende Gruppe muß an den Parameter
<literal>security.mac.seeotheruids.specificgid=<replaceable>XXX</replaceable></literal>
übergeben werden, wobei <replaceable>XXX</replaceable> die ID
der Gruppe ist, die von der Richtlinie ausgenommen werden
soll.</para>
</listitem>
<listitem>
<para>
<literal>security.mac.seeotheruids.primarygroup_enabled</literal>
kann verwendet werden, um eine spezifische,
<emphasis>primäre</emphasis> Nutzergruppe von der Richtlinie
auszuschliessen. Dieser Parameter und
<literal>security.mac.seeotheruids.specificgid_enabled</literal>
schließen einander aus.</para>
</listitem>
</itemizedlist>
</sect1>
<sect1 id="mac-bsdextended">
<title>Das MAC Modul bsdextended</title>
<indexterm>
<primary>MAC</primary>
<secondary>File System Firewall Policy</secondary>
</indexterm>
<para>Modulname: <filename>mac_bsdextended.ko</filename></para>
<para>Parameter in der Kernelkonfiguration:
<literal>options MAC_BSDEXTENDED</literal></para>
<para>Bootparameter: <literal>mac_bsdextended_load="YES"</literal></para>
<para>Das Modul &man.mac.bsdextended.4; erstellt eine Firewall für
das Dateisystem und ist eine Erweiterung des sonst üblichen
Rechtemodells. Es erlaubt einem Administrator einen Regelsatz zum
Schutz von Dateien, Werkzeugen und Verzeichnissen in der
Dateisystemhierarchie zu erstellen, der einer Firewall ähnelt.
Sobald auf ein Objekt im Dateisystem zugegriffen werden soll, wird eine
Liste von Regel abgearbeitet, bis eine passende Regel gefunden wird
oder die Liste zu Ende ist. Das Verhalten kann durch die Änderung
des &man.sysctl.8; Parameters
<literal>security.mac.bsdextended.firstmatch_enabled</literal>
eingestellt werden. Ähnlich wie bei den anderen Firewallmodulen
in &os; wird eine Datei erstellt, welche die Zugriffsregeln
enthält. Diese wird beim Systemstart durch eine Variable in
&man.rc.conf.5; eingebunden.</para>
<para>Der Regelsatz kann mit dem Programm &man.ugidfw.8; eingepflegt
werden, welches eine Syntax bereitstellt, die der von &man.ipfw.8;
gleicht. Weitere Werkzeuge können auch selbst erstellt werden,
indem die Funktionen der Bibliothek &man.libugidfw.3; verwendet
werden.</para>
<para>Bei der Arbeit mit diesem Modul ist äußerste Vorsicht
geboten - falscher Gebrauch kann den Zugriff auf Teile des Dateisystems
komplett unterbinden.</para>
<sect2>
<title>Beispiele</title>
<para>Nachdem das Modul &man.mac.bsdextended.4; erfolgreich geladen
wurde, zeigt das folgende Kommando die gegenwärtig aktiven Regeln
an:</para>
<screen>&prompt.root; <userinput>ugidfw list</userinput> 0 slots, 0 rules</screen>
<para>Wie erwartet, sind keine Regeln definiert. Das bedeutet, das auf
alle Teile des Dateisystems zugegriffen werden kann. Um eine Regel zu
definieren, die jeden Zugriff durch Nutzer blockiert und nur die Rechte
von <username>root</username> unangetastet läßt, muß
lediglich dieses Kommando ausgeführt werden:</para>
<screen>&prompt.root; <userinput>ugidfw add subject not uid root new object not uid root mode n</userinput></screen>
<para>Das ist allerdings keine gute Idee, da nun allen Nutzern der
Zugriff auf selbst die einfachsten Programme wie <command>ls</command>
untersagt wird. Angemessener wäre etwas wie:</para>
<screen>&prompt.root; <userinput>ugidfw set 2 subject uid <replaceable>user1</replaceable> object uid <replaceable>user2</replaceable> mode n</userinput>
&prompt.root; <userinput>ugidfw set 3 subject uid <replaceable>user1</replaceable> object gid <replaceable>user2</replaceable> mode n</userinput></screen>
<para>Diese Befehle bewirken, dass <username>user1</username> keinen
Zugriff mehr auf Dateien und Programme hat, die
<username><replaceable>user2</replaceable></username> gehören.
Dies schließt das Auslesen von Verzeichniseinträgen ein.
</para>
<para>Anstelle <option>uid</option> <username>user1</username>
könnte auch <option>not uid
<replaceable>user2</replaceable></option> als Parameter übergeben
werden. Dies würde diesselben Einschränkungen für alle
Nutzer bewirken anstatt nur einen einzigen.</para>
<note>
<para><username>root</username> ist von diesen Einstellungen nicht
betroffen.</para>
</note>
<para>Dies sollte als Überblick ausreichen, um zu verstehen, wie das
Modul &man.mac.bsdextended.4; helfen kann, das Dateisystem
abzuschotten. Weitere Informationen bieten die Manpages
&man.mac.bsdextended.4; und &man.ugidfw.8;.</para>
</sect2>
</sect1>
<sect1 id="mac-ifoff">
<title>Das MAC Modul ifoff</title>
<indexterm>
<primary>MAC Interface Silencing Policy</primary>
</indexterm>
<para>Modulname: <filename>mac_ifoff.ko</filename></para>
<para>Parameter für die Kernelkonfiguration:
<literal>options MAC_IFOFF</literal>
</para>
<para>Bootparameter: <literal>mac_ifoff_load="YES"</literal></para>
<para>Das Modul &man.mac.ifoff.4; ist einzig dazu da,
Netzwerkschnittstellen im laufenden Betrieb zu deaktivieren oder zu
verhindern, das Netzwerkschnittstellen während der Bootphase
gestartet werden. Dieses Modul benötigt für seinen Betrieb
weder Labels, die auf dem System eingerichtet werden müssen, noch
hat es Abhängigkeiten zu anderen MAC Modulen.</para>
<para>Der größte Teil der Kontrolle geschieht über die im
folgenden aufgelisteten <command>sysctl</command>-Parameter:</para>
<itemizedlist>
<listitem>
<para><literal>security.mac.ifoff.lo_enabled</literal> schaltet den
gesamten Netzwerkverkehr auf der Loopback-Schnittstelle &man.lo.4; an
bzw. aus.</para>
</listitem>
<listitem>
<para><literal>security.mac.ifoff.bpfrecv_enabled</literal> macht das
Gleiche für den Berkeley Paket Filter &man.bpf.4;.</para>
</listitem>
<listitem>
<para><literal>security.mac.ifoff.other_enabled</literal>
schaltet den Verkehr für alle anderen
Netzwerkschnittstellen.</para>
</listitem>
</itemizedlist>
<para>Die wahrscheinlich häufigste Nutzung von &man.mac.ifoff.4; ist
die Überwachung des Netzwerks in einer Umgebung, in der kein
Netzwerkverkehr während des Bootvorgangs erlaubt werden soll. Eine
andere mögliche Anwendung wäre ein Script, das mit Hilfe von
<filename role="package">security/aide</filename> automatisch alle
Schnittstellen blockiert, sobald Dateien in geschützten
Verzeichnissen angelegt oder verändert werden.</para>
</sect1>
<sect1 id="mac-portacl">
<title>Das MAC Modul portacl</title>
<indexterm>
<primary>MAC Port Access Control List Policy</primary>
</indexterm>
<para>Modulname: <filename>mac_portacl.ko</filename></para>
<para>Parameter für die Kernelkonfiguration:
<literal>options MAC_PORTACL</literal></para>
<para>Bootparameter: <literal>mac_portacl_load="YES"</literal></para>
<para>Mit Hilfe des Moduls &man.mac.portacl.4; können die Anbindungen
an die lokalen <acronym>TCP</acronym> und <acronym>UDP</acronym> Ports
durch eine Vielzahl von <command>sysctl</command> Variablen
beschränkt werden. Genauer gesagt ermöglicht
&man.mac.portacl.4; Nutzern ohne <username>root</username>-Rechten den
Zugriff auf zu bestimmende privilegierte Ports, also denen innerhalb der
ersten 1024.</para>
<para>Sobald das Modul geladen wurde, ist die Richtlinie für alle
Sockets verfügbar. Die folgenden Variablen können für die
Konfiguration verwendet werden:</para>
<itemizedlist>
<listitem>
<para><literal>security.mac.portacl.enabled</literal> schaltet die
Anwendung der Richtlinie ein oder aus.</para>
</listitem>
<listitem>
<para><literal>security.mac.portacl.port_high</literal> gibt den
höchsten Port an, der von der Richtlinie &man.mac.portacl.4;
betroffen sein soll.</para>
</listitem>
<listitem>
<para><literal>security.mac.portacl.suser_exempt</literal> nimmt, wenn
es einen Wert ungleich Null zugewiesen bekommt,
<username>root</username> von der Richtlinie aus.</para>
</listitem>
<listitem>
<para><literal>security.mac.portacl.rules</literal> enthält als
Wert die eigentliche <literal>mac_portacl</literal>
Richtlinie.</para>
</listitem>
</itemizedlist>
<para>Die eigentliche Konfiguration der <literal>mac_portacl</literal>
Richtlinie wird der <command>sysctl</command>-Variablen
<literal>security.mac.portacl.rules</literal> als Zeichenkette der Form
<literal>rule[,rule,...]</literal> übergeben. Jede einzelne Regel
hat die Form <literal>idtype:id:protocol:port</literal>. Der Parameter
<parameter>idtype</parameter> ist entweder <literal>uid</literal> oder
<literal>gid</literal> und wird verwendet, um den Parameter
<parameter>id</parameter> als Nutzer-ID oder Gruppen-ID zu kennzeichnen.
Der Parameter <parameter>protocol</parameter> gibt an, ob die Regel
ür <acronym>TCP</acronym> oder <acronym>UDP</acronym> gelten soll
(indem man den Wert auf <literal>tcp</literal> oder
<literal>udp</literal> setzt). Und der letzte Parameter,
<parameter>port</parameter>, enthält die Nummer des Ports, auf den
der angegebene Nutzer bzw. die angegebene Gruppe Zugriff erhalten
soll.</para>
<note>
<para>Da der Regelsatz direkt vom Kernel ausgewertet wird, können
nur Zahlenwerte übergeben werden. Das heißt, Namen von
Nutzern, Gruppen oder Dienstnamen aus der Datei
<filename>/etc/services</filename> funktionieren nicht.</para>
</note>
<para>Auf &unix;-artigen Betriebssystemen sind die Ports kleiner 1024
privilegierten Prozessen vorbehalten, müssen also mit als/von
<username>root</username> gestartet werden und weiterhin laufen. Damit
&man.mac.portacl.4; die Vergabe von Ports kleiner als 1024 an nicht
privilegierte Prozesse übernehmen kann, muß die &unix;
Standardeinstellung deaktiviert werden. Dazu ändert man die
&man.sysctl.8; Variablen
<literal>net.inet.ip.portrange.reservedlow</literal> und
<literal>net.inet.ip.portrange.reservedhigh</literal> auf den Wert
<quote>0</quote>.</para>
<para>Weiterführende Informationen entnehmen Sie bitte den unten aufgeführten Beispielen oder der Man-Page &man.mac.portacl.4;!</para>
<sect2>
<title>Beispiele</title>
<para>Die folgenden Beispiele sollten ein wenig Licht in die obige
Diskussion bringen:</para>
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.port_high=1023</userinput>
&prompt.root; <userinput>sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0</userinput></screen>
<para>Zunächst bestimmen wir, dass &man.mac.portacl.4; für alle
privilegierten Ports gelten soll und deaktivieren die normale
&unix;-Beschränkung.</para>
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.suser_exempt=1</userinput></screen>
<para> Da <username>root</username> von dieser Richtlinie nicht
beeinträchtigt werden soll, setzen wir hier
<literal>security.mac.portacl.suser_exempt</literal> auf einen Wert
ungleich Null. Das Modul &man.mac.portacl.4; ist nun so eingerichtet,
wie es &unix;-artige Betriebssysteme normal ebenfalls tun.</para>
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:80:tcp:80</userinput></screen>
<para>Nun erlauben wir dem Nutzer mit der <acronym>UID</acronym> 80,
normalerweise dem Nutzer <username>www</username>, den Port 80 zu verwenden. Dadurch kann der Nutzer <username>www</username> einen Webserver
betreiben, ohne dafür mit <username>root</username>-Privilegien
ausgestattet zu sein.</para>
<screen>&prompt.root; <userinput>sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995</userinput></screen>
<para>Hier wird dem Nutzer mit der <acronym>UID</acronym> 1001 erlaubt,
die <acronym>TCP</acronym> Ports 110 (<quote>pop3</quote>) und 995
(<quote>pop3s</quote>) zu verwenden. Dadurch kann dieser Nutzer einen
Server starten, der Verbindungen an diesen beiden Ports annehmen
kann.</para>
</sect2>
</sect1>
<sect1 id="mac-partition">
<title>Das MAC Modul partition</title>
<indexterm>
<primary>MAC Process Partition Policy</primary>
</indexterm>
<para>Modulname: <filename>mac_partition.ko</filename></para>
<para>Parameter für die Kernelkonfiguration:
<literal>options MAC_PARTITION</literal>
</para>
<para>Bootparameter <literal>mac_partition_load="YES"</literal></para>
<para>Die Richtlinie &man.mac.partition.4; setzt Prozesse in spezielle
<quote>Partitionen</quote>, entsprechend dem zugewiesenen
<acronym>MAC</acronym> Label. Man kann sich das vorstellen wie eine
spezielle Art &man.jail.8;, auch wenn das noch kein wirklich guter
Vergleich ist.</para>
<para>Es wird empfohlen, dieses Modul durch einen Eintrag in
&man.loader.conf.5; zu aktivieren, so dass die Richtlinie während
des Bootvorganges eingebunden wird.</para>
<para>Der Großteil der Konfiguration geschieht mit dem Kommando
&man.setpmac.8;, wie gleich erklärt wird. Außerdem gibt es folgenden <command>sysctl</command> Parameter für diese Richtlinie.</para>
<itemizedlist>
<listitem>
<para><literal>security.mac.partition.enabled</literal> erzwingt die
Verwendung von <acronym>MAC</acronym>
Prozeß-Partitionen.</para>
</listitem>
</itemizedlist>
<para>Sobald diese Richtlinie aktiv ist, sehen Nutzer nur noch ihre eigenen
Prozesse, und alle anderen Prozesse, die ebenfalls derselben
Prozeß-Partition zugeordnet sind. Sie können jedoch nicht auf
Prozesse oder Werkzeuge außerhalb des Anwendungsbereich dieser
Partition zugreifen. Das bedeutet unter anderem, das ein Nutzer, der
einer Klasse <literal>insecure</literal> zugeordnet ist, nicht auf das
Kommando <command>top</command> zugreifen kann - wie auch auf viele
anderen Befehle, die einen eigenen Prozeß erzeugen.</para>
<para>Um einen Befehl einer Prozeß-Partition zuzuordnen, muß
dieser durch das Kommando <command>setpmac</command> mit einem Label
versehen werden:</para>
<screen>&prompt.root; <userinput>setpmac partition/13 top</userinput></screen>
<para>Diese Zeile fügt das Kommando <command>top</command> dem
Labelsatz für Nutzer der Klasse <literal>insecure</literal> hinzu,
sofern die Partition 13 mit der Klasse <literal>insecure</literal>
übereinstimmt. Beachten Sie, dass alle Prozesse, die von Nutzern
dieser Klasse erzeugt werden, das Label <literal>partition/13</literal>
erhalten, und dieses auch nicht durch den Nutzer geändert werden
kann.</para>
<sect2>
<title>Beispiele</title>
<para>Der folgende Befehl listet die vergebenen Label für
Prozeß-Partitionen und die laufenden Prozesse auf.</para>
<screen>&prompt.root; <userinput>ps Zax</userinput></screen>
<para>Das nächste Kommando liefert das Label der
Prozeß-Partition eines anderen Nutzers
<username>trhodes</username> und dessen gegenwärtig laufenden
Prozesse zurück.</para>
<screen>&prompt.root; <userinput>ps -ZU trhodes</userinput></screen>
<note>
<para>Jeder Nutzer kann die Prozesse in der Prozeß-Partition von
<username>root</username> betrachten, solange nicht die Richtlinie
&man.mac.seeotheruids.4; geladen wurde.</para>
</note>
<para>Eine ausgefeilte Umsetzung dieser Richtlinie deaktiviert alle
Dienste in <filename>/etc/rc.conf</filename> und startet diese dann
später durch ein Skript, das jedem Dienst das passende Label
zuordnet.</para>
<note>
<para>Die folgenden Richtlinien verwenden Zahlenwerte anstatt der drei
Standardlabels. Diese Optionen, und ihre Grenzen, werden in den
zugehörigen Manpages genauer erklärt.</para>
</note>
</sect2>
</sect1>
<sect1 id="mac-mls">
<title>Das MAC Modul Multi-Level Security</title>
<indexterm>
<primary>MAC Multi-Level Security Policy</primary>
</indexterm>
<para>Modulname: <filename>mac_mls.ko</filename></para>
<para>Parameter für die Kernelkonfiguration: <literal>options
MAC_MLS</literal></para>
<para>Bootparameter: <literal>mac_mls_load="YES"</literal></para>
<para>Die Richtlinie &man.mac.mls.4; kontrolliert die Zugriffe zwischen
Subjekten und Objekten, indem sie den Informationsfluß strengen
Regeln unterwirft.</para>
<para>In <acronym>MLS</acronym> Umgebungen wird jedem Subjekt oder Objekt
ein <quote>Freigabe</quote>-Level zugeordnet, und diese werden wiederum
zu einzelnen Verbünden zusammengefaßt. Da diese Freigabe-
oder Anfälligkeits-Level Zahlen größer 6000 erreichen
können, ist es für jeden Systemadministrator eine undankbare
Aufgabe, jede Entität von Grund auf zu konfigurieren. Zum
Glück gibt es 3 <quote>instant</quote> Labels, die in der Richtlinie
zur Anwendung bereit stehen.</para>
<para>Diese drei Labels heißen <literal>mls/low</literal>,
<literal>mls/equal</literal> und <literal>mls/high</literal>. Da sie in
den Manpages &man.mac.mls.4; ausführlich beschrieben werden, gibt
es hier nur einen kurzen Abriß:</para>
<itemizedlist>
<listitem>
<para>Das Label <literal>mls/low</literal> ist eine niedrige
Einstellung, die von allen anderen dominiert werden darf. Alles, was
mit <literal>mls/low</literal> versehen wird, hat ein niedriges
Freigabe-Level und darf auf keine Informationen zugreifen, denen ein
höheres Freigabe-Level zugeordnet wurde. Einem Objekt mit
diesem Label kann außerdem keine Information durch ein Objekt
höherer Freigabe übergeben werden, es kann also auch nicht
durch solche Objekte editiert oder überschrieben werden.</para>
</listitem>
<listitem>
<para>Das Label <literal>mls/equal</literal> wird an Objekte vergeben,
die von dieser Richtlinie ausgenommen werden sollen.</para>
</listitem>
<listitem>
<para>Das Label <literal>mls/high</literal> verkörpert das
höchstmögliche Freigabe-Level. Objekte, denen dieses Label
zugeordnet wird, dominieren alle anderen Objekte des Systems.
Trotzdem können sie Objekten mit einem niedrigeren
Freigabe-Level keine Informationen zuspielen.</para>
</listitem>
</itemizedlist>
<para><acronym>MLS</acronym> bietet:</para>
<itemizedlist>
<listitem>
<para>Eine hierarchische Sicherheitsschicht und Zuordnung
nichthierarchischer Kategorien;</para>
</listitem>
<listitem>
<para>Feste Regeln: kein <quote>Read-Up</quote>, kein
<quote>Write-Down</quote> (ein Subjekt kann nur Objekte gleicher oder
<emphasis>niedrigerer</emphasis> Stufe lesen, und es kann nur Objekte
gleicher oder <emphasis>höherer</emphasis> Stufe
schreiben);</para>
</listitem>
<listitem>
<para>Geheimhaltung (indem unangemessene Offenlegung von Daten
verhindert wird);</para>
</listitem>
<listitem>
<para>Eine Basis zum Entwerfen von Systemen, die Daten verschiedener
Vertraulichkeitsebenen gleichzeitig handhaben sollen (ohne das
geheime und vertrauliche Informationen untereinander ausgetauscht
werden können).</para>
</listitem>
</itemizedlist>
<para>Nachfolgend werden die <command>sysctl</command>-Variablen
vorgestellt, die für die Einrichtung spezieller Dienste und
Schnittstellen vorhanden sind.</para>
<itemizedlist>
<listitem>
<para><literal>security.mac.mls.enabled</literal> schaltet die
Richtlinie <acronym>MLS</acronym> ein (oder aus).</para>
</listitem>
<listitem>
<para><literal>security.mac.mls.ptys_equal</literal> sorgt dafür,
dass während der Initialisierung alle &man.pty.4;-Geräte
als <literal>mls/equal</literal> gekennzeichnet werden.</para>
</listitem>
<listitem>
<para><literal>security.mac.mls.revocation_enabled</literal> sorgt
dafür, dass die Zugriffsrechte von Objekten wieder
zurückgesetzt werden, nachdem deren Label vorübergehend auf
ein niedrigeres Freigabe-Level geändert wurde.</para>
</listitem>
<listitem>
<para><literal>security.mac.mls.max_compartments</literal> gibt die
maximale Anzahl von Verbünden an. Im Prinzip ist es die
höchste Nummer eines Verbundes auf dem System.</para>
</listitem>
</itemizedlist>
<para>Um die Labels der <acronym>MLS</acronym> Richtlinie zu bearbeiten
verwendet man &man.setfmac.8;. Um ein Objekt zu kennzeichnen, benutzen
Sie folgendes Kommando:</para>
<screen>&prompt.root; <userinput>setfmac mls/5 test</userinput></screen>
<para>Um das <acronym>MLS</acronym>-Label der Datei
<filename>test</filename> auszulesen, verwenden Sie dieses
Kommando:</para>
<screen>&prompt.root; <userinput>getfmac test</userinput></screen>
<para>Dies ist eine Zusammenstellung der Merkmale von
<filename>test</filename>. Ein anderer Ansatz ist, für diese
Richtlinie eine Konfigurationsdatei in <filename
class="directory">/etc</filename> abzulegen, die alle Informationen
enthält und mit der dann das Kommando <command>setfmac</command>
gefüttert wird. Diese Vorgehensweise wird erklärt, nachdem
alle Richtlinien vorgestellt wurden.</para>
<sect2>
<title>Verbindlicher Vertraulichkeit in der Planungsphase</title>
<para>Mit dem Richtlinienmodul <literal> Multi-Level Security</literal>
bereitet sich ein Administrator darauf vor, den Fluß
vertraulicher Informationen zu kontrollieren. Beim Starten der
Richtlinie ist immer <literal>mls/low</literal> voreingestellt -
alles kann auf alles zugreifen. Der Administrator ändert dies
während der eigentlichen Konfiguration, indem er die
Vertraulichkeit bestimmter Objekte erhöht.</para>
<para>Jenseits der drei Grundeinstellungen des Labels kann der
Administrator einzelne Nutzer oder Nutzergruppen nach Bedarf
zusammenschließen und den Informationsaustausch zwischen diesen
gestatten oder unterbinden. Es ist sicher eine Vereinfachung, die
Freigabe-Level mit Begriffen wie <literal>vertraulich</literal>,
<literal>geheim</literal> oder <literal>streng geheim</literal> zu
bezeichnen. Einige Administratoren erstellen einfach verschiedene
Gruppen auf der Ebene von gegenwärtigen Projekten. Ungeachtet der
Herangehensweise bei der Klassifizierung muß ein gut durchdachter
Plan existieren, bevor eine derart einengende Richtlinie umgesetzt
wird.</para>
<para>Exemplarisch für die Anwendung dieses Moduls bzw. dieser
Richtlinie seien angeführt:</para>
<itemizedlist>
<listitem>
<para>Ein E-Commerce Webserver</para>
</listitem>
<listitem>
<para>Ein Dateiserver, der vertrauliche Informationen einer Firma
oder eines Konzerns speichert</para>
</listitem>
<listitem>
<para>Umgebungen in Finanzeinrichtungen</para>
</listitem>
</itemizedlist>
<para>Der unsinnigste Einsatzort für diese Richtlinie wäre ein
Arbeitsplatzrechner mit nur zwei oder drei Benutzern.</para>
</sect2>
</sect1>
<sect1 id="mac-biba">
<title>Das MAC Modul Biba</title>
<indexterm>
<primary>MAC Biba Integrity Policy</primary>
</indexterm>
<para>Modulname: <filename>mac_biba.ko</filename></para>
<para>Parameter für die Kernelkonfiguration:
<literal>options MAC_BIBA</literal></para>
<para>Bootparameter: <literal>mac_biba_load="YES"</literal></para>
<para>Das Modul &man.mac.biba.4; lädt die <acronym>MAC</acronym> Biba
Richtlinie. Diese ähnelt stark der <acronym>MLS</acronym>
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
<acronym>MLS</acronym> Richtlinie den aufsteigenden Fluß regelt.
In gewissen Sinne treffen dieses und das vorangegangene Unterkapitel also
auf beide Richtlinien zu.</para>
<para>In einer Biba-Umgebung wird jedem Subjekt und jedem Objekt ein
<quote>Integritäts</quote>-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.</para>
<para>Die unterstützten Labels heißen
<literal>biba/low</literal>, <literal>biba/equal</literal> und
<literal>biba/high</literal>. Sie werden im Folgenden
erklärt:</para>
<itemizedlist>
<listitem>
<para><literal>biba/low</literal> 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.</para>
</listitem>
<listitem>
<para>Das Label <literal>biba/equal</literal> ist, wie der aufmerksame
Leser sicherlich schon ahnt, für die Ausnahmen dieser Richtlinie
gedacht und sollte nur diesen Ausnahmen entsprechenden Objekten
verliehen werden.</para>
</listitem>
<listitem>
<para><literal>biba/high</literal> 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.</para>
</listitem>
</itemizedlist>
<para>Biba stellt bereit:</para>
<itemizedlist>
<listitem>
<para>Hierarchische Integritätsstufen mit einem Satz
nichthierarchischer Integritätskategorien;</para>
</listitem>
<listitem>
<para>Festgeschriebene Regeln: kein <quote>Write-Up</quote>, kein
<quote>Read-Down</quote> (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);</para>
</listitem>
<listitem>
<para>Integrität (es wird die Echtheit der Daten
gewährleistet, indem unangemessene Veränderungen verhindert
werden);</para>
</listitem>
<listitem>
<para>Eine Abstufung der Gewährleistung (im Gegensatz zu MLS, bei
der eine Abstufung der Vertraulichkeit vorgenommen wird).</para>
</listitem>
</itemizedlist>
<para>Folgende <command>sysctl</command> Parameter werden zur Nutzung der
Biba-Richtlinie angeboten:</para>
<itemizedlist>
<listitem>
<para><literal>security.mac.biba.enabled</literal> zum
Aktivieren/Deaktivieren der Richtlinie auf dem Zielsystem.</para>
</listitem>
<listitem>
<para><literal>security.mac.biba.ptys_equal</literal> wird verwendet,
um die Biba-Richtlinie auf der &man.pty.4;-Schnittstelle zu
deaktivieren.</para>
</listitem>
<listitem>
<para><literal>security.mac.biba.revocation_enabled</literal>
erzwingt das Zurücksetzen des Labels, falls dieses zeitweise
geändert wurde um ein Subjekt zu dominieren.</para>
</listitem>
</itemizedlist>
<para>Um Einstellungen der Biba Richtlinie für Systemobjekte zu
verändern werden die Befehle <command>setfmac</command> und
<command>getfmac</command> verwendet:</para>
<screen>&prompt.root; <userinput>setfmac biba/low test</userinput>
&prompt.root; <userinput>getfmac test</userinput>
test: biba/low</screen>
<sect2>
<title>Verbindliche Integrität in der Planungsphase</title>
<para>Integritä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.</para>
<para>Das Modul &man.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.</para>
<para>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
<literal>biba/high</literal> 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 <quote>allgemeiner Nutzer</quote> zusammenfaßt, die
für diese Bereiche lediglich lesenden Zugriff erhalten
sollen.</para>
<para>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.</para>
</sect2>
</sect1>
<sect1 id="mac-lomac">
<title>Das MAC Modul LOMAC</title>
<indexterm>
<primary>MAC LOMAC</primary>
</indexterm>
<para>Modulname: <filename>mac_lomac.ko</filename></para>
<para>Parameter für die Kernelkonfiguration:
<literal>options MAC_LOMAC</literal></para>
<para>Bootparameter: <literal>mac_lomac_load="YES"</literal></para>
<para>Anders als die Biba Richtlinie erlaubt die &man.mac.lomac.4;
Richtlinie den Zugriff auf Objekte niedrigerer Integrität nur,
nachdem das Integritätslevel gesenkt wurde. Dadurch wird eine
Störung derIntegritätsregeln verhindert.</para>
<para>Die <acronym>MAC</acronym> Version der <quote>Low-Watermark</quote>
Richtlinie, die nicht mit der älteren &man.lomac.4;-Implementierung
verwechselt werden darf, arbeitet fast genauso wie Biba. Anders ist,
dass hier <quote>schwebende</quote> Label verwendet werden, die ein
Herunterstufen von Subjekten durch Hilfsverbünde ermöglichen.
Dieser zweite Verbund wird in der Form <literal>[auxgrade]</literal>
angegeben und sollte in etwa aussehen wie <literal>lomac/10[2]</literal>,
wobei die Ziffer zwei (2) hier den Hilfsverbund abbildet.</para>
<para>Die <acronym>MAC</acronym> Richtlinie <literal> LOMAC</literal>
beruht auf einer durchgängigen Etikettierung aller Systemobjekte mit
Integritätslabeln, die Subjekten das Lesen von Objekten niedriger
Integrität gestatten und dann das Label des Subjektes herunterstufen
- um zukünftige Schreibvorgänge auf Objekte hoher
Integrität zu unterbinden. Dies ist die Funktion der Option
<literal>[auxgrade]</literal>, die eben vorgestellt wurde. Durch sie
erhält diese Richtlinie eine bessere Kompatibilität und die
Initialisierung ist weniger aufwändig als bei der Richtlinie
Biba.</para>
<sect2>
<title>Beispiele</title>
<para>Wie schon bei den Richtlinien Biba und <acronym>MLS</acronym>
werden die Befehle <command>setfmac</command> und
<command>setpmac</command> verwendet, um die Labels an den
Systemobjekten zu setzen:</para>
<screen>&prompt.root; <userinput>setfmac /usr/home/trhodes lomac/high[low]</userinput>
&prompt.root; <userinput>getfmac /usr/home/trhodes</userinput> lomac/high[low]</screen>
<para>Beachten Sie, dass hier der Hilfswert auf <literal>low</literal>
gesetzt wurde - dieses Leistungsmerkmal ist nur in der
<acronym>MAC</acronym> <literal>LOMAC</literal> Richtlinie
enthalten.</para>
</sect2>
</sect1>
<sect1 id="mac-implementing">
<title>Beispiel 1: Nagios in einer MAC Jail</title>
<indexterm>
<primary>Nagios in a MAC Jail</primary>
</indexterm>
<para>Die folgende Demonstration setzt eine sichere Umgebung mithilfe
verschiedener <acronym>MAC</acronym> Module und sorgfältig
konfigurierter Richtlinien um. Es handelt sich jedoch nur um einen Test
und sollte nicht als Antwort auf jedes Problem in Fragen Sicherheit
gesehen werden. Eine Richtlinie nur umzusetzen und dann einfach laufen
zu lassen, funktioniert nie und kann eine echte Arbeitsumgebung in eine
Katastrophe stürzen.</para>
<para>Bevor es losgeht, muß jedes Dateisystem mit der Option
<option>multilabel</option>, wie weiter oben beschrieben, markiert
werden. Dies nicht zu tun, führt zu Fehlern. Außerdem
müssen die Ports <filename
role="package">net-mngt/nagios-plugins</filename>, <filename
role="package">net-mngt/nagios</filename> und <filename
role="package">www/apache13</filename> installiert und konfiguriert sein,
so dass sie ordentlich laufen.</para>
<sect2>
<title>Erstellen einer Nutzerklasse <literal>insecure</literal></title>
<para>Beginnen wir die Prozedur mit dem Hinzufügen einer
Nutzerklasse in der Datei <filename>/etc/login.conf</filename>:</para>
<programlisting>insecure:\
: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=biba/10(10-10):</programlisting>
<para>Zusätzlich fügen wir beim Standardnutzer folgende Zeile
hinzu:</para>
<programlisting>:label=biba/high:</programlisting>
<para>Anschließend muß die Datenbank neu erstellt
werden:</para>
<screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
</sect2>
<sect2>
<title>Boot-Konfiguration</title>
<para>Starten Sie den Rechner noch nicht neu. Fügen Sie
zunächst noch die folgenden Zeilen in die Datei
<filename>/boot/loader.conf</filename> ein, damit die benötigten
Module während des Systemstarts geladen werden:</para>
<programlisting>mac_biba_load="YES"
mac_seeotheruids_load="YES"</programlisting>
</sect2>
<sect2>
<title>Nutzer einrichten</title>
<para>Ordnen Sie den Superuser <username>root</username> der Klasse
<literal>default</literal> zu:</para>
<screen>&prompt.root; <userinput>pw usermod root -L default</userinput></screen>
<para>Alle Nutzerkonten, die weder <username>root</username> noch
Systemkonten sind, brauchen nun eine Loginklasse, da sie sonst keinen
Zugriff auf sonst übliche Befehle erhalten, wie bspw. &man.vi.1;.
Das folgende <command>sh</command> Skript wird diese Aufgabe
erledigen:</para>
<screen>&prompt.root; <userinput>for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \</userinput>
<userinput>/etc/passwd`; do pw usermod $x -L default; done;</userinput></screen>
<para>Verschieben Sie die Nutzer <username>nagios</username> und
<username>www</username> in die <literal>insecure</literal>
Klasse:</para>
<screen>&prompt.root; <userinput>pw usermod nagios -L insecure</userinput></screen>
<screen>&prompt.root; <userinput>pw usermod www -L insecure</userinput></screen>
</sect2>
<sect2>
<title>Die Kontextdatei erstellen</title>
<para>Nun muß eine Kontextdatei erstellt werden. Die folgende
Beispieldatei soll dazu in <filename>/etc/policy.contexts</filename>
gespeichert werden:</para>
<programlisting># This is the default BIBA policy for this system.
# System:
/var/run biba/equal
/var/run/* biba/equal
/dev biba/equal
/dev/* biba/equal
/var biba/equal
/var/spool biba/equal
/var/spool/* biba/equal
/var/log biba/equal
/var/log/* biba/equal
/tmp biba/equal
/tmp/* biba/equal
/var/tmp biba/equal
/var/tmp/* biba/equal
/var/spool/mqueue biba/equal
/var/spool/clientmqueue biba/equal
# For Nagios:
/usr/local/etc/nagios
/usr/local/etc/nagios/* biba/10
/var/spool/nagios biba/10
/var/spool/nagios/* biba/10
# For apache
/usr/local/etc/apache biba/10
/usr/local/etc/apache/* biba/10
</programlisting>
<para>Die Richtlinie erzwingt Sicherheit, indem der
Informationsfluß Einschränkungen unterworfen wird. In der
vorliegenden Konfiguration kann kein Nutzer, weder
<username>root</username> noch andere, auf
<application>Nagios</application> zugreifen. Konfigurationsdateien und
die Prozesse, die Teil von <application>Nagios</application> sind,
werden durch unsere <acronym>MAC</acronym> vollständig
abgegrenzt.</para>
<para>Die Kontextdatei kann nun vom System eingelesen werden, indem
folgender Befehl ausgeführt wird:</para>
<screen>&prompt.root; <userinput>setfmac -ef /etc/policy.contexts /</userinput>
&prompt.root; <userinput>setfmac -ef /etc/policy.contexts /</userinput></screen>
<note>
<para>Das obenstehende Dateisystem-Layout kann, je nach Umgebung, sehr
unterschiedlich aussehen. Außerdem muß es auf jedem
einzelnen Dateisystem ausgeführt werden.</para>
</note>
<para>In die Datei <filename>/etc/mac.conf</filename> müssen nun
noch diese Änderungen eingetragen werden:</para>
<programlisting>default_labels file ?biba
default_labels ifnet ?biba
default_labels process ?biba
default_labels socket ?biba
</programlisting>
</sect2>
<sect2>
<title>Netzwerke einbinden</title>
<para>Tragen Sie die folgende Zeile in die Datei
<filename>/boot/loader.conf</filename> ein:</para>
<programlisting>security.mac.biba.trust_all_interfaces=1</programlisting>
<para>Und das Folgende gehört in Datei <filename>rc.conf</filename>
zu den Optionen für die Netzwerkkarte. Falls die
Netzwerkverbindung(-en) via <acronym>DHCP</acronym>
konfiguriert werden, muß man dies nach jedem Systemstart
eigenhändig nachtragen:</para>
<programlisting>maclabel biba/equal</programlisting>
</sect2>
<sect2>
<title>Testen der Konfiguration</title>
<indexterm>
<primary>MAC Configuration Testing</primary>
</indexterm>
<para>Versichern Sie sich, dass der Webserver und
<application>Nagios</application> nicht automatisch geladen werden und
starten Sie den Rechner neu. Prüfen Sie nun, ob
<username>root</username> wirklich keinen Zugriff auf die Dateien im
Konfigurationsverzeichnis von <application>Nagios</application> hat.
Wenn <username>root</username> den Befehl &man.ls.1; auf
<filename>/var/spool/nagios</filename> ausführen kann, ist
irgendwas schief gelaufen. Es sollte ein <errorname>permission
denied</errorname> Fehler ausgegeben werden.</para>
<para>Wenn alles gut aussieht, können
<application>Nagios</application>,
<application>Apache</application> und
<application>Sendmail</application> gestartet werden - allerdings auf
eine Weise, die unserer Richtlinie gerecht wird. Zum Beispiel durch die
folgenden Kommandos:</para>
<screen>&prompt.root; <userinput>cd /etc/mail && make stop && \
setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \
setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart</userinput></screen>
<para>Versichern Sie sich lieber doppelt, dass alles ordentlich
läuft. Wenn nicht, prüfen Sie die Logs und Fehlermeldungen.
Verwenden Sie das &man.sysctl.8; Werkzeug um die Sicherheitsrichtlinie
&man.sysctl.8; zu deaktivieren und versuchen Sie dann alles noch einmal
zu starten.</para>
<note>
<para>Der Superuser kann den Vollzug der Richtlinie schalten und die
Konfiguration ohne Furcht verändern. Folgender Befehl stuft
eine neu gestartete Shell herunter:</para>
<screen>&prompt.root; <userinput>setpmac biba/10 csh</userinput></screen>
<para>Um dies zu vermeiden, werden die Nutzer durch &man.login.conf.5;
eingeschränkt. Wenn &man.setpmac.8; einen Befehl
außerhalb der definierten Schranken ausführen soll, wird
ein Fehler zurückgeliefert. In so einem Fall muß
<username>root</username> auf <literal>biba/high(high-high)</literal>
gesetzt werden.</para>
</note>
</sect2>
</sect1>
<sect1 id="mac-userlocked">
<title>Beispiel 2: User Lock Down</title>
<para>Grundlage dieses Beispiels ist ein relativ kleines System zur
Datenspeicherung mit weniger als 50 Benutzern. Diese haben die
Möglichkeit, sich einzuloggen und dürfen nicht nur Daten
speichern, sondern auch auf andere Ressourcen zugreifen.</para>
<para>Die Richtlinien &man.mac.bsdextended.4; und &man.mac.seeotheruids.4;
können gleichzeitig eingesetzt werden. Zusammen kann man mit ihnen
nicht nur den Zugriff auf Systemobjekte einschränken, sondern auch
Nutzerprozesse verstecken.</para>
<para>Beginnen Sie, indem Sie die folgende Zeile in die Datei
<filename>/boot/loader.conf</filename> eintragen:</para>
<programlisting>mac_seeotheruids_load="YES"</programlisting>
<para>Die Richtlinie &man.mac.bsdextended.4; wird durch den
anschließenden Eintrag in <filename>/etc/rc.conf</filename>
hinzugefügt:</para>
<programlisting>ugidfw_enable="YES"</programlisting>
<para>Die Standardregeln, welche in
<filename>/etc/rc.bsdextended</filename> gespeichert sind, werden zum
Systemstart geladen. Sie müssen aber noch angepaßt werden.
Da dieser Computer nur Nutzern dienen soll und weitere Dienste gestartet
werden, kann alles bis auf die beiden letzten Zeilen auskommentiert
werden. Das sorgt dafür dass jeder Nutzer seine eigenen
Systemobjekte erhält.</para>
<para>Nun fügen wir alle benötigten Nutzer auf der Maschine hinzu
und starten neu. Zum Testen der Einstellungen loggen Sie sich parallel
zwei mal mit unterschiedlichen Nutzernamen ein und starten Sie das
Kommando <command>ps aux</command>. Dort sehen Sie, dass Sie die
Prozesse des anderen Nutzers nicht sehen können. Versuchen Sie,
&man.ls.1; auf das Heimatverzeichnis eines anderen Nutzers
auszuführen. Auch dieser Versuch wird fehlschlagen.</para>
<para>Solange nicht die speziellen <command>sysctl</command>-Variablen
geändert wurden, hat der Superuser noch vollen Zugriff. Sobald auch
diese Einstellungen angepaßt wurden, führen Sie ruhig auch
den obigen Test als <username>root</username> aus.</para>
<note>
<para>Wenn ein neuer Benutzer hinzugefügt wird, ist für diesen
zunächst keine &man.mac.bsdextended.4; Regel im Regelsatz
vorhanden. Schnelle Abhilfe schafft hier, einfach das Kernelmodul mit
&man.kldunload.8; zu entladen und mit &man.kldload.8; erneut
einzubinden.</para>
</note>
</sect1>
<sect1 id="mac-troubleshoot">
<title>Fehler im MAC beheben</title>
<indexterm>
<primary>MAC Troubleshooting</primary>
</indexterm>
<para>Während der Entwicklung des Frameworks haben einige Nutzer auf
Probleme hingewiesen. Einige davon werden hier aufgeführt:</para>
<sect2>
<title>Die Option <option>multilabel</option> greift nicht auf der
<filename>/</filename>-Partition</title>
<para>Es scheint, dass etwa jedem fünfzigsten Nutzer dieses Problem
widerfährt. Und in der Tat - auch wir kennen es aus der
Entwicklung. Genauere Untersuchungen dieses <quote>Bugs</quote>
machten uns glauben, dass es sich entweder um einen Fehler in oder eine
fehlerhafte Interpretation der Dokumentation handelt. Warum auch immer
dieser Fehler auftritt - er kann mit folgender Prozedur behoben
werden:</para>
<procedure>
<step>
<para>Öffnen Sie die Datei <filename>/etc/fstab</filename> und
setzen Sie die Rootpartition auf <option>ro</option> wie
<quote>read-only</quote>.</para>
</step>
<step>
<para>Starten Sie in den Einzelnutzermodus.</para>
</step>
<step>
<para>Rufen Sie <command>tunefs</command> <option>-l enable</option>
für <filename>/</filename> auf.</para>
</step>
<step>
<para>Starten Sie in den Mehrbenutzermodus.</para>
</step>
<step>
<para>Führen Sie <command>mount</command>
<option>-urw</option> <filename>/</filename> aus und ändern
Sie anschließend in der Datei <filename>/etc/fstab</filename>
die Option <option>ro</option> zurück in <option>rw</option>.
Starten Sie das System noch einmal neu.</para>
</step>
<step>
<para>Achten Sie besonders auf die Ausgabe von
<command>mount</command> um sich zu versichern, dass die
<option>multilabel</option> korrekt für das root-Dateisystem
gesetzt wurde.</para>
</step>
</procedure>
</sect2>
<sect2>
<title>Mit der aktivierten MAC kann ich keinen X11 Server starten</title>
<para>Dies kann durch die Richtlinie <literal>partition</literal>
oder einer fehlerhaften Verwendung einer Richtlinie, die mit Labels
arbeitet, auftreten. Zum debuggen versuchen Sie folgendes:</para>
<procedure>
<step>
<para>Schauen Sie sich die Fehlermeldungen genau an. Wenn der Nutzer
einer <literal>insecure</literal> Klasse angehört, ist
wahrscheinlich die Richtlinie <literal>partition</literal> die
Ursache. Versuchen Sie, die Nutzerklasse auf
<literal>default</literal> zu stellen und danach die Datenbank mit
<command>cap_mkdb</command> zu erneuern. Wenn das Problem dadurch
nicht gelöst wird, gehen Sie weiter zu Schritt 2.</para>
</step>
<step>
<para>Gehen Sie die Label-Richtlinien Schritt für Schritt
nocheinmal durch. Achten Sie darauf, dass für den Nutzer, bei
dem das Problem auftritt, für X11 und das Verzeichnis
<filename class="directory">/dev</filename> alle Einstellungen
korrekt sind.</para>
</step>
<step>
<para>Falls all dies nicht helfen sollte, senden Sie die
Fehlermeldung und eine Beschreibung ihrer Arbeitsumgebung an die
(englisch-sprachige) TrustedBSD Diskussionsliste auf der <ulink
url="http://www.TrustedBSD.org">TrustedBSD</ulink> Webseite oder an
die &a.questions; Mailingliste.</para>
</step>
</procedure>
</sect2>
<sect2>
<title>Error: &man..secure.path.3; cannot stat
<filename>.login_conf</filename></title>
<para>Wenn ich versuche, von <username>root</username> zu einem anderen
Nutzer des Systems zu wechseln, erhalte ich die Fehlermeldung
<errorname>_secure_path: unable to state .login_conf</errorname>.
</para>
<para>Diese Meldung wird gewöhnlich ausgegeben, wenn der Nutzer ein
höhere Label-Einstellung hat als der, dessen Identität man
annehmen möchte. Ausführlich: Wenn ein Nutzer
<username>joe</username> als <option>biba/low</option> gelabelt wurde,
kann <username>root</username>, der <option>biba/high</option> als
Voreinstellung trägt, das Heimatverzeichnis von
<username>joe</username> nicht einsehen. Das passiert unabhänig
davon, ob <username>root</username> vorher mit <command>su</command>
die Identität von <username>joe</username> angenommen hat oder
nicht, da das Label sich nicht ändert. Hier haben wir also einen
Fall, in dem das Gewährleistungsmodell von Biba verhindert, das
der Superuser Objekte einer niedrigeren Integrität betrachten
kann.</para>
</sect2>
<sect2>
<title>Der Nutzer <username>root</username> ist kaputt!</title>
<para>Im normalen oder sogar im Einzelbenutzermodus wird
<username>root</username> nicht anerkannt. Das Kommando
<command>whoami</command> liefert 0 (null) und <command>su</command>
liefert <errorname>who are you?</errorname> zurück. Was geht da
vor?</para>
<para>Das kann passieren, wenn eine Label-Richtlinie ausgeschaltet wird -
entweder durch &man.sysctl.8; oder wenn das Richtlinienmodul entladen
wurde. Wenn eine Richtlinie deaktiviert oder auch nur
vorübergehen deaktiviert wird, muß die
Befähigungsdatenbank neu konfiguriert werden, d.h. die
<option>label</option> Option muß entfernt werden.
Überprüfen Sie, ob alle <option>label</option> Einträge
aus der Datei <filename>/etc/login.conf</filename> entfernt wurden und
bauen Sie die Datenbank mit <command>cap_mkdb</command> neu.</para>
<para>Dieser Fehler kann auch auftreten, wenn eine Richtlinie den Zugriff
auf die Datei <filename>master.passwd</filename> einschränkt.
Normalerweise passiert das nur, wenn ein Administrator ein Label an
diese Datei vergibt, das mit der allgemeingültigen Richtlinie, die
das System verwendet, in Konflikt steht. In solchen Fällen werden
die Nutzerinformationen vom System ausgelesen und jeder weitere Zugriff
wird blockiert, sobald das neue Label greift. Wenn man die Richtlinie
via &man.sysctl.8; ausschaltet, sollte es erstmal wieder gehen.</para>
</sect2>
</sect1>
</chapter>