17.17. Problemen oplossen met het MAC-raamwerk
Terug | Hoofdstuk 17. Verplichte Toegangscontrole (MAC) | Volgende

## 17.17. Problemen oplossen met het MAC-raamwerk

Tijdens de ontwikkeling hebben een aantal gebruikers problemen aangegeven met normale instellingen. Hieronder worden een aantal van die problemen beschreven:

### 17.17.1. De optie `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:

1. Wijzig `/etc/fstab` en stel de rootpartitie in op `ro` voor alleen-lezen.

2. Herstart in enkele-gebruikersmodus.

3. Draai `tunefs` `-l enable` op `/`.

4. Herstart in normale modus.

5. Draai `mount` `-urw` `/` en wijzig `ro` terug in `rw` in `/etc/fstab` en start het systeem opnieuw.

6. Controleer de uitvoer van `mount` om zeker te zijn dat `multilabel` juist is ingesteld op het rootbestandssysteem.

### 17.17.2. X11-server start niet na MAC

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:

1. 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.

2. 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.

3. 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.

### 17.17.3. Error: _secure_path(3) cannot stat `.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.

### 17.17.4. De gebruikersnaam `root` is stuk!

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.

Terug | Omhoog | Volgende
17.16. Gebruikers afsluiten | Begin | Hoofdstuk 18. Security Event Auditing