A PAM-hitelesítés kézzel működik, OpenVPN-szolgáltatásként viszont elbukik

A PAM-on keresztüli hitelesítés sikeres lehet, amikor kézzel indítja a klienst, és AUTH_FAILED hibával bukik el, amint a systemd ugyanazt a profilt indítja. A jelszó nem változik ezek között a futások között; ami változik, az a PAM-ot kérdező folyamat körüli megkötések halmaza. A PAM egy segéden keresztül válaszol, amelynek saját hitelesítő adatainak megváltoztatására való képessége éppen az, amit egy megerősített unit eltávolít. Találja meg ezt a segédet és a szükséges határt, mielőtt a képességlistához nyúl.

Az unix_chkpwd az a bináris, amely a PAM kérdésére válaszol

Helyi jelszavas hitelesítéssel a pam_unix ritkán olvassa magát a hash-fájlt. Lefuttatja a unix_chkpwd-t, amelyet a disztribúciók setuid root vagy setgid shadow módban telepítenek, hogy egy jelszó ellenőrizhető legyen egy olyan folyamat nevében, amelynek semmi dolga a /etc/shadow olvasásával. Távolítsa el az identitás megszerzésének képességét, és a segéd nem tudja befejezni az ellenőrzést, ezért a modul egyszerű hitelesítési hibát ad vissza.

A hiba aztán minden naplóban, amelyet a kliens lát, hitelesítőadat-problémának tűnik. Ez a csapda: a kliens azt jelenti, amit a PAM mondott neki, a PAM pedig csak azt jelenti, hogy a verem nemet mondott. A segéd kézi futtatása rootként szintén nem bizonyít semmit, mert olyan jogosultsági utat gyakorol, amelyet a szolgáltatás soha nem használ. Olvassa el a unitot, amelyet a systemd valóban betöltött, majd a rendszernaplót a megtett kísérlethez. Ez a két nézet elválasztja a sandbox-problémát a rossz jelszó problémájától.

A unitot olvassa el, mielőtt a jelszónaplót olvasná

Egy csomagolt unit tartalmazhat olyan drop-int, amelyet nem Ön írt, és a tényleges konfiguráció az összevont eredmény. Nyomtassa ki a unitot úgy, ahogy a systemd látja, együtt azokkal a sandbox-beállításokkal, amelyek eldöntik, hogy a segéd felemelheti-e magát. Ebben a szakaszban a csak olvasási ellenőrzés elegendő.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

Az első parancs megmutatja, honnan származik a unit és a drop-injei, ami azért fontos, mert egy hónapokkal ezelőtt hozzáadott felülírás tovább él, mint az emlékezet arról, miért létezik. A második kiírja azokat a sandbox-értékeket, amelyektől a következő két szakasz függ.

Hasonlítsa össze, amit lát, egy ugyanilyen disztribúciójú és verziójú működő gazdagéppel. A User, CapabilityBoundingSet vagy NoNewPrivileges eltérése konkrét nyom; a prózai megjegyzések eltérése nem az. Írja fel az értékeket, mielőtt bármit megváltoztat, mert egy mozgó célhoz való későbbi összehasonlítás semmit nem bizonyít. Ha a szolgáltatás jogosultság nélküli fiókkal és üres bounding-halmazzal fut, a segédnek szinte semmi sem áll rendelkezésére.

A hitelesítőadat-átalakítás, a fájlhozzáférés és a szabályzat három határ

Kezdje azzal, ami az exec során történik. Egy setuid bináris vagy fájlképességeket hordozó fájl hitelesítőadat-átalakítást vált ki, így a keletkező identitás nem a hívó folytatása. A bounding-halmaz korlátozza, mit szerezhet be egy ilyen fájl, és a NoNewPrivileges teljesen blokkolja a setuid, setgid és fájlképesség megszerzését. Bármelyikük megállíthatja a segédet, miközben a szolgáltatás minden más funkciója sértetlen marad.

Ezután válassza szét a széles diszkrecionális megkerülést a szűk olvasási hozzáféréstől. A CAP_DAC_OVERRIDE szinte mindenhol átugorja a diszkrecionális ellenőrzéseket, míg a CAP_DAC_READ_SEARCH saját további jogosultságaival lefedi az olvasást és a könyvtárbejárást. Különböző eszközök különböző hatósugárral, és egyik sem annak a megfogalmazása, hogy hagyd a PAM-ot olvasni a shadow-fájlt.

Végül kérdezze meg, hogy a kötelező szabályzat egyáltalán engedélyezi-e a műveletet. Egy Linux-képesség nem írja felül a SELinuxot, és birtoklása semmit nem bizonyít egy type enforcement szabályról. Kezelje a fájlhozzáférés-megtagadást és a képesség-megtagadást különböző bizonyítékként, mert különböző javításokat és gyakran különböző tulajdonosokat neveznek meg. Olvassa el a rekord minden mezőjét, ne csak a denied szót. Melyik végrehajtható fájl cselekedett, melyik tartományban futott, milyen típusú célhoz ért, melyik objektumosztály vett részt, és melyik engedélyt tagadta meg a szabályzat – mindegyik másképp szűkíti a választ.

Húzza ki a megtagadást az auditnaplóból

Egy kényszerítő gazdagépen az auditnyom az egyetlen hely, amely megtagadást rögzít. Kérdezze le a közelmúlt eseményeit, és a sikertelen bejelentkezés időbélyegéhez viszonyítva olvassa őket, nem ahhoz az időhöz, amikor elkezdte a vizsgálatot.

ausearch -m AVC,USER_AVC -ts recent

Az üres eredmény nem az ártatlanság bizonyítéka. Azt jelenti, hogy vagy az auditálás nem gyűjt, vagy az ablaka kihagyta a kísérletet, és mindkét lehetőséget ki kell zárni, mielőtt a szabályzatot kizárná.

A Red Hat SELinux-hibaelhárítási útmutatója a címke- és konfigurációellenőrzéseket az allow-szabályok létrehozása elé helyezi, ami ennél a problémánál is a helyes sorrend. Egy rosszul címkézett segéd-bináris és egy szabályzati rés hasonló megtagadásokat okoz, de különböző javításokat igényel. Egy címkézési hiba allow-szabályának létrehozása elrejti a hibát, és a következő csomagfrissítésre hagyja annak visszahozatalát. Erősítse meg a telepített segéd címkéjét, mielőtt bármilyen szabályzatot ír.

Bizonyítsa a változtatást egy elfogadott és egy elutasított bejelentkezéssel

Csak azt a határt változtassa meg, amelyet bemutatott, majd tesztelje mindkét kimenetet. Egy fióknak, amelynek hitelesítenie kell, sikerülnie kell, egy rossz jelszavú fióknak pedig továbbra is el kell buknia. Egy olyan változtatás, amely minden kísérletet sikeressé tesz, eltávolította a hitelesítést ahelyett, hogy megjavította volna.

Végezzen valódi kapcsolódási kísérletet, és olvassa el a naplót közvetlenül utána. A javítást bizonyító sor az adott kísérlet pam_unix(openvpn:auth) bejegyzése: sikeres hitelesítést kell mutatnia, és egyetlen AVC rekord sem viselheti ugyanazt a másodpercet.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

Egy működő alagút újracsatlakozást is igényel, mert a sandbox-változások gyakrabban törik meg a második kapcsolatot, mint az elsőt. Ellenőrizze a létrejött socketet az újracsatlakozás után, és erősítse meg, hogy ugyanaz a unit szolgálja ki továbbra is.