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.