Das FreeBSD-Handbuch
Zurück Kapitel 17. Verbindliche Zugriffskontrolle Weiter

17.17. Fehler im MAC beheben

Während der Entwicklung des Frameworks haben einige Nutzer auf Probleme hingewiesen. Einige davon werden hier aufgeführt:

17.17.1. Die Option multilabel greift nicht auf der /-Partition

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 “Bugs” 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:

  1. Öffnen Sie die Datei /etc/fstab und setzen Sie die Rootpartition auf ro wie “read-only”.

  2. Starten Sie in den Einzelnutzermodus.

  3. Rufen Sie tunefs -l enable für / auf.

  4. Starten Sie in den Mehrbenutzermodus.

  5. Führen Sie mount -urw / aus und ändern Sie anschließend in der Datei /etc/fstab die Option ro zurück in rw. Starten Sie das System noch einmal neu.

  6. Achten Sie besonders auf die Ausgabe von mount um sich zu versichern, dass die multilabel korrekt für das root-Dateisystem gesetzt wurde.

17.17.2. Mit der aktivierten MAC kann ich keinen X11 Server starten

Dies kann durch die Richtlinie partition oder einer fehlerhaften Verwendung einer Richtlinie, die mit Labels arbeitet, auftreten. Zum debuggen versuchen Sie folgendes:

  1. Schauen Sie sich die Fehlermeldungen genau an. Wenn der Nutzer einer insecure Klasse angehört, ist wahrscheinlich die Richtlinie partition die Ursache. Versuchen Sie, die Nutzerklasse auf default zu stellen und danach die Datenbank mit cap_mkdb zu erneuern. Wenn das Problem dadurch nicht gelöst wird, gehen Sie weiter zu Schritt 2.

  2. 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 /dev alle Einstellungen korrekt sind.

  3. Falls all dies nicht helfen sollte, senden Sie die Fehlermeldung und eine Beschreibung ihrer Arbeitsumgebung an die (englisch-sprachige) TrustedBSD Diskussionsliste auf der TrustedBSD Webseite oder an die FreeBSD general questions Mailingliste.

17.17.3. Error: _secure_path(3) cannot stat .login_conf

Wenn ich versuche, von root zu einem anderen Nutzer des Systems zu wechseln, erhalte ich die Fehlermeldung “_secure_path: unable to state .login_conf”.

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 joe als biba/low gelabelt wurde, kann root, der biba/high als Voreinstellung trägt, das Heimatverzeichnis von joe nicht einsehen. Das passiert unabhänig davon, ob root vorher mit su die Identität von joe 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.

17.17.4. Der Nutzer root ist kaputt!

Im normalen oder sogar im Einzelbenutzermodus wird root nicht anerkannt. Das Kommando whoami liefert 0 (null) und su liefert “who are you?” zurück. Was geht da vor?

Das kann passieren, wenn eine Label-Richtlinie ausgeschaltet wird - entweder durch 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 label Option muß entfernt werden. Überprüfen Sie, ob alle label Einträge aus der Datei /etc/login.conf entfernt wurden und bauen Sie die Datenbank mit cap_mkdb neu.

Dieser Fehler kann auch auftreten, wenn eine Richtlinie den Zugriff auf die Datei master.passwd 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 sysctl(8) ausschaltet, sollte es erstmal wieder gehen.

Zurück Zum Anfang Weiter
Beispiel 2: User Lock Down Nach oben Security Event Auditing

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <[email protected]>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <[email protected]>.