PAM-todennus toimii käsin mutta epäonnistuu OpenVPN-palveluna

PAM:n kautta todennus voi onnistua, kun ajat asiakkaan käsin, ja epäonnistua AUTH_FAILED-virheellä, kun systemd käynnistää saman profiilin. Salasana ei muutu näiden ajojen välillä; muuttuu se rajoitusten joukko, joka ympäröi prosessia, joka kysyy PAM:lta. PAM vastaa apuohjelman kautta, jonka kyky vaihtaa omia tunnistetietojaan on juuri se, minkä kovennettu unit poistaa. Löydä tämä apuohjelma ja sen tarvitsema raja ennen kuin kosket kyvykkyysluetteloon.

unix_chkpwd on binääritiedosto, joka vastaa PAM:n kysymykseen

Paikallisessa salasanatodennuksessa pam_unix lukee harvoin itse hash-tiedostoa. Se suorittaa unix_chkpwd, jonka jakelut asentavat setuid root- tai setgid shadow -muotoon, jotta yksi salasana voidaan tarkistaa sellaisen prosessin puolesta, jolla ei ole mitään asiaa lukea tiedostoa /etc/shadow. Poista kyky saada tämä identiteetti, niin apuohjelma ei voi suorittaa tarkistusta loppuun, joten moduuli palauttaa tavallisen todennusvirheen.

Silloin virhe näyttää tunnistetieto-ongelmalta jokaisessa lokissa, jonka asiakas näkee. Se on ansa: asiakas raportoi, mitä PAM sille kertoi, ja PAM raportoi vain, että pino sanoi ei. Apuohjelman ajaminen käsin rootina ei myöskään todista mitään, koska se harjoittaa käyttöoikeuspolkua, jota palvelu ei koskaan käytä. Lue unit, jonka systemd todella latasi, ja sitten järjestelmäloki tehdystä yrityksestä. Nämä kaksi näkymää erottavat sandbox-ongelman väärän salasanan ongelmasta.

Lue unit ennen kuin luet salasanalokin

Paketoitu unit voi sisältää drop-inin, jota et kirjoittanut, ja tehokas kokoonpano on yhdistetty tulos. Tulosta unit sellaisena kuin systemd sen näkee, yhdessä sandbox-asetusten kanssa, jotka päättävät, voiko apuohjelma korottaa itsensä. Vain luku -tarkastus riittää tässä vaiheessa.

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

Ensimmäinen komento näyttää, mistä unit ja sen drop-init tulevat, millä on merkitystä, koska kuukausia sitten lisätty ohitus elää pidempään kuin muisto siitä, miksi se on olemassa. Toinen tulostaa sandbox-arvot, joista seuraavat kaksi osiota riippuvat.

Vertaile näkemääsi saman jakelun ja version toimivaan isäntään. Ero kohdassa User, CapabilityBoundingSet tai NoNewPrivileges on konkreettinen vihje; ero proosakommenteissa ei ole. Kirjoita arvot muistiin ennen minkään muuttamista, koska myöhempi vertailu liikkuvaan maaliin ei todista mitään. Jos palvelu toimii ilman käyttöoikeuksia olevalla tilillä ja tyhjällä bounding-joukolla, apuohjelmalla ei ole juuri mitään, millä työskennellä.

Tunnistetietojen muunnos, tiedostopääsy ja käytäntö ovat kolme rajaa

Aloita siitä, mitä execin aikana tapahtuu. setuid-binääri tai tiedostokyvykkyyksiä kantava tiedosto laukaisee tunnistetietojen muunnoksen, joten tuloksena oleva identiteetti ei ole kutsujan jatko. Bounding-joukko rajoittaa, mitä tällainen tiedosto voi hankkia, ja NoNewPrivileges estää setuid-, setgid- ja tiedostokyvykkyyksien hankkimisen kokonaan. Mikä tahansa näistä kolmesta voi pysäyttää apuohjelman jättäen kaikki muut palvelun toiminnot ehjiksi.

Erota seuraavaksi laaja harkinnanvarainen ohitus kapeasta lukupääsystä. CAP_DAC_OVERRIDE ohittaa harkinnanvaraiset tarkistukset lähes kaikkialla, kun taas CAP_DAC_READ_SEARCH kattaa lukemisen ja hakemistojen läpikäynnin omilla lisävaltuuksillaan. Ne ovat eri työkaluja, joilla on eri vaikutussäde, eikä kumpikaan ole kirjoitusasu lauseelle anna PAM:n lukea shadow-tiedostoa.

Kysy lopuksi, salliiko pakollinen käytäntö toiminnon ylipäätään. Linux-kyvykkyys ei ohita SELinuxia, eikä sen hallussapito todista mitään type enforcement -säännöstä. Käsittele tiedostopääsyn hylkäystä ja kyvykkyyden hylkäystä eri todisteina, koska ne nimeävät eri korjaukset ja usein eri omistajat. Lue jokainen tietueen kenttä etkä vain sanaa denied. Mikä suoritettava tiedosto toimi, missä domeenissa se ajettiin, minkä tyyppistä kohdetta se koski, mikä objektiluokka oli mukana ja minkä luvan käytäntö hylkäsi – kukin kaventaa vastausta eri tavalla.

Vedä hylkäys esiin audit-lokista

Valvovassa isännässä audit-jälki on ainoa paikka, joka tallentaa hylkäyksen. Kysy viimeisimmät tapahtumat ja lue ne epäonnistuneen kirjautumisen aikaleiman mukaan, älä sen ajan mukaan, jolloin aloitit tutkinnan.

ausearch -m AVC,USER_AVC -ts recent

Tyhjä tulos ei ole todiste syyttömyydestä. Se tarkoittaa joko, että auditointi ei kerää, tai että ikkunasi ohitti yrityksen, ja molemmat mahdollisuudet on suljettava pois ennen kuin suljet pois käytännön.

Red Hatin SELinuxin vianmääritysohje asettaa tunniste- ja kokoonpanotarkistukset ennen allow-sääntöjen luomista, mikä on oikea järjestys myös tässä ongelmassa. Väärin merkitty apuohjelmabinääri ja käytännön aukko tuottavat samankaltaisia hylkäyksiä mutta vaativat erilaisia korjauksia. Allow-säännön luominen merkintävirheelle piilottaa vian ja jättää seuraavan pakettipäivityksen tuomaan sen takaisin. Vahvista asennetun apuohjelman tunniste ennen minkään käytännön kirjoittamista.

Todista muutos yhdellä hyväksytyllä ja yhdellä hylätyllä kirjautumisella

Muuta vain rajaa, jonka osoitit, ja testaa sitten molemmat tulokset. Tilin, jonka pitäisi todennus, on onnistuttava, ja väärällä salasanalla olevan tilin on edelleen epäonnistuttava. Muutos, joka saa jokaisen yrityksen onnistumaan, on poistanut todennuksen sen korjaamisen sijaan.

Tee todellinen yhteysyritys ja lue loki heti sen jälkeen. Korjauksen todistava rivi on kyseisen yrityksen pam_unix(openvpn:auth)-merkintä: siinä pitäisi lukea todennus onnistui, eikä yhdelläkään AVC-tietueella saa olla samaa sekuntia.

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

Toimiva tunneli tarvitsee myös uudelleenyhdistämisen, koska sandbox-muutokset rikkovat toisen yhteyden useammin kuin ensimmäisen. Tarkista muodostettu socket uudelleenyhdistämisen jälkeen ja vahvista, että sama unit palvelee sitä edelleen.