Tijdens de ontwikkeling hebben een aantal gebruikers problemen aangegeven met normale instellingen. Hieronder worden een aantal van die problemen beschreven:
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.
.login_conf
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.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.