FreeBSD kézikönyv
Előző | Fejezet 16. Kötelező hozzáférés-vezérlés | Következő

# 16.17. A hibák elhárítása a MAC rendszerben

A fejlesztés fázisában bizonyos normál konfigurációval rendelkező felhasználók gondokat jeleztek. Ezeket foglaljuk most itt össze:

## 16.17.1. A `multilabel` beállítás nem adható meg a `/` állományrendszerre

A `multilabel` beállítás nem marad meg a rendszerindító (`/`) partíciómon!

A tapasztalatok szerint körülbelül minden ötvenedik felhasználó szembesül ezzel a problémával, és mi is találkozunk vele a kezdeti konfigurációk kialakítása során. Ennek az úgynevezett “hibának” a behatóbb tanulmányozása során arra jutottunk, hogy ez többnyire vagy a hibás dokumentálásból vagy a dokumentáció félreértelmezéséből ered. Független attól, hogy ez mitől is következett be, a következő lépések megtételével orvosolhatjuk:

1. Nyissuk meg az `/etc/fstab` állományt és adjuk meg a rendszerindító partíciónak az `ro`, vagyis az írásvédett (read-only) beállítást.

2. Indítsuk újra a gépet egyfelhasználós módban.

3. A `tunefs` `-l enable` parancsot futtassuk le a `/` állományrendszeren.

4. Indítsuk újra a rendszert normál módban.

5. Adjuk ki a `mount` `-urw` `/` parancsot, majd az `/etc/fstab` állományban írjuk át a `ro` beállítást az `rw` értékre és megint indítsuk újra a rendszert.

6. Alaposan nézzük át a `mount` parancs kimenetét és győzödjünk meg róla, hogy a `multilabel` opció valóban beállítódott a rendszerindító állományrendszerre.

## 16.17.2. A MAC után nem lehet indítani az X11 szervert

Nem indul az X, miután MAC-kel kialakítottunk egy biztonságos környezetet!

Ezt vagy a MAC `partition` házirendje okozza, vagy az egyik címkékeket használó házirend helytelen beállítása. A következő módon deríthetjük ki az okát:

1. Figyelmesen olvassuk el a hibaüzenetet: ha a felhasználó az `insecure` osztály tagja, akkor a `partition` házirend lesz a bűnös. Próbáljuk meg a felhasználót visszatenni a `default` osztályba és a `cap_mkdb` paranccsal újragenerálni az adatbázist. Ha ez nem segít a problémán, akkor haladjunk tovább.

2. Alaposan ellenőrizzük a címkékhez tartozó házirendeket. Vizsgáljuk meg, hogy a kérdeses felhasználó esetében a házirendet és az X11 alkalmazást, valamint a `/dev` eszközöket tényleg jól állítottuk be.

3. Ha az iméntiek egyik sem oldja meg gondunkat, küldjük el a hibaüzenetet és a környezetünk rövid leírását a a TrustedBSD honlapjáról elérhető TrustedBSD levelezési lista vagy a FreeBSD general questions levelezési lista címére.

## 16.17.3. Hiba: _secure_path(3) cannot stat `.login_conf`

Amikor a rendszerben megpróbálok a `root` felhasználóról átváltani egy másik felhasználóra, a “`_secure_path: unable to state .login_conf`” hibaüzenet jelenik meg.

Ez az üzenet általában akkor látható, amikor a felhasználó nagyobb értékű címkével rendelkezik annál, mint akivé válni akar. Például vegyük a `joska` nevű felhasználót a rendszerben, aki az alap `biba/low` címkével rendelkezik. A `root` felhasználó, akinek `biba/high` címkéje van, nem láthatja `joska` felhasználói könyvtárát. Ez attól függetlenül megtörténik, hogy a `root` a `su` paranccsal váltott át a `joska` nevű felhasználóra vagy sem. Egy ilyen helyzetben a Biba sértetlenségi modellje nem fogja engedni a `root` felhasználóra számára, hogy láthassa a kevésbé sértetlen objektumokat.

## 16.17.4. A `root` felhasználó nem megy!

A rendszer normál vagy egyfelhasználós módban sem ismeri fel a `root` felhasználót. A `whoami` parancs 0 (nullát) ad vissza és a `su` parancs pedig annyit mond: “`who are you?`” (“`ki vagy?`”). Mi történhetett?

Ez csak olyankor történhet, ha a címkézési házirendet nem engedélyezzük, vagy a sysctl(8) használatával, vagy pedig a modul eltávolításával. Ha a házirendet letiltjuk vagy ideiglenesen letiltódik, akkor a bejelentkezési tulajdonságokat tároló adatbázist a `label` beállítás eltávolításával kell újrakonfigurálni. A `login.conf` állományból ne felejtsük el kivenni az összes `label` beállítást és a `cap_mkdb` paranccsal újragenerálni az adatbázist.

Ilyen akkor is előfordulhat, amikor a házirend valamilyen módon korlátozza a `master.passwd` állomány vagy adatbázis elérhetőségét. Ezt általában az okozza, hogy a rendszergazda az állományt olyan címke alatt módosítja, amely ütközik a rendszerben alkalmazott általános házirenddel. Ebben az esetekben a rendszer próbálja meg beolvasni a felhasználók adatait, azonban mivel közben az állomány új címkét örökölt, nem fér hozzá. Ha a sysctl(8) paranccsal letiltjuk a házirendet, minden vissza fog térni a rendes kerékvágásba.

Előző | Tartalom | Következő
A felhasználók korlátozása | Fel | Biztonsági események vizsgálata

Ha kérdése van a FreeBSD-vel kapcsolatban, a következő címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon: <gabor@FreeBSD.org>.