Tijdens de ontwikkeling hebben een aantal gebruikers problemen aangegeven met normale instellingen. Hieronder worden een aantal van die problemen beschreven:
multilabel kan niet ingeschakeld worden op /De vlag multilabel blijft niet ingeschakeld op de
rootpartitie (/)!
Het lijkt er inderdaad op dat een paar procent van de gebruikers dit probleem heeft. Nadere analyse van het probleem doet vermoeden dat deze zogenaamde “bug” het resultaat is van òfwel onjuiste documentatie òfwel verkeerde interpretatie van de documentatie. Hoe het probleem ook is ontstaan, met de volgende stappen is het te verhelpen:
Wijzig /etc/fstab en stel de rootpartitie in op ro voor alleen-lezen.
Herstart in enkele-gebruikersmodus.
Draai tunefs -l enable op
/.
Herstart in normale modus.
Draai mount -urw / en wijzig ro terug in rw in /etc/fstab en start het
systeem opnieuw.
Controleer de uitvoer van mount om zeker te zijn dat
multilabel juist is ingesteld op het
rootbestandssysteem.
Na het instellen van een beveiligde omgeving met MAC start X niet meer!
Dit kan komen door de MAC-beleidseenheid partition of door een verkeerde labeling van een van de MAC-labeling beleidseenheden. Probeer als volgt te debuggen:
Controleer de foutmelding. Als de gebruiker in de klasse insecure zit, kan de beleidseenheid partition het probleem zijn. Zet de klasse voor de gebruiker terug naar de klasse default en herbouw de database met het commando cap_mkdb. Ga naar stap twee als hiermee het probleem niet is opgelost.
Controleer de labelbeleidseenheden nog een keer. Stel zeker dat het beleid voor de bewuste gebruiker, de X11-applicatie, en de onderdelen van /dev juist zijn ingesteld.
Als geen van beide methodes het probleem oplossen, stuur dan de foutmelding en een beschrijving van de omgeving naar de TrustedBSD-discussielijsten van de TrustedBSD website of naar de FreeBSD algemene vragen mailinglijst mailinglijst.
Bij het wisselen van de gebruiker root naar een andere gebruiker in het systeem, verschijnt de foutmelding “_secure_path: unable to state .login_conf”.
Deze melding komt meestal voor als de gebruiker een hogere labelinstelling heeft
dan de gebruiker waarnaar wordt gewisseld. Als bijvoorbeeld gebruiker joe een standaardlabel biba/low
heeft, dan kan gebruiker root, die een label biba/high heeft, de thuismap van joe
niet zien. Dit gebeurt zonder rekening te houden met de mogelijkheid dat root met su de identiteit van joe heeft aangenomen. In dit scenario staat het
integriteitsmodel van Biba niet toe dat root objecten kan
zien van een lager integriteitsniveau.
In normale, of zelfs in enkelegebruikersmodus, wordt root niet herkend. Het commando whoami geeft 0 (nul) terug en su heeft als resultaat “who are you?”. Wat is er aan de hand?
Dit kan gebeuren als een labelbeleid is uitgeschakeld, òfwel door sysctl(8) òf doordat
de beleidsmodule niet meer is geladen. Als de beleidseenheid (tijdelijk) is
uitgeschakeld dan moet de database met aanmeldmogelijkheden opnieuw worden
ingesteld, waarbij de optie label wordt verwijderd. Er
dient voor te worden zorggedragen dat het bestand login.conf wordt ontdaan van alle opties met label, waarna de database opnieuw gebouwd kan worden met cap_mkdb.
Dit kan ook gebeuren als een beleid toegang verhinderd tot het bestand of de database master.passwd. Meestal wordt dit veroorzaakt door een beheerder die het bestand veranderd onder een label welke conflicteert met het globale beleid dat gebruikt wordt op het systeem. In deze gevallen wordt de gebruikersinformatie gelezen door het systeem en wordt de toegang geblokkeerd omdat het bestand het nieuwe label erft. Zet het beleid uit door middel van sysctl(8) en alles zou weer normaal moeten zijn.