Root päätteessä, SELinuxin alla hylätty: miksi koukku epäonnistuu

Suoritat up-skriptin root-käyttäjänä, se valmistuu, ja sama skripti epäonnistuu, kun palvelu kutsuu sitä. Tiedoston käyttöoikeuksissa ei ole muuttunut mikään, joten luonnollinen seuraava askel on löysätä niitä uudelleen, mikä ei korjaa mitään. SELinux-isännässä ratkaiseva tekijä ei usein ole se, kuka prosessi on, vaan se, missä toimialueessa se toimii, ja root rajoitetun toimialueen sisällä on edelleen rajoitettu.

Sama komento, kaksi eri tietoturvatoimialuetta

Tyypin pakotus arvioi lähdetoimialueen, kohdeleiman ja pyydetyn toiminnon yhdessä. Pääteistuntosi toimii rajoittamattomassa tai hallinnollisessa toimialueessa, ja taustapalvelu toimii toimialueessa, joka sen yksikölle on määritetty. Siksi identtiset komennot tuottavat erilaisia päätöksiä, ja ero on tarkoituksellinen eikä käytännön virhe.

Siksi kahden suorituksen vertailu on hyödyllistä vain, jos vertailet niiden konteksteja. Suorita sama komento kuoresta ja koukusta; kuoren versio todistaa, että binääri on olemassa ja argumentit ovat oikein, mutta ei todista mitään siitä, saako palvelu suorittaa sen. Suorita se molemmilla tavoilla ja vertaa toimialueita, älä vain paluukoodeja. Juuri tämä vertailu muuttaa epämääräisen käyttöoikeusvalituksen täsmälliseksi kysymykseksi yhdestä toimialueesta ja yhdestä leimasta.

Tämän vian klassinen muoto on apuohjelma, joka kutsuu ulkoista työkalua. Itse koukku voi olla sallittu, kun taas työkalu, jonka se kutsuu, kantaa leimaa, jota palvelun toimialue ei saa suorittaa, tai kirjoittaa hakemistoon, jonka leima kieltää sen.

Lue AVC-tietue koukun virheen vierestä

AVC-hylkäys nimeää kentät, jotka ratkaisevat tapauksen: prosessin lähdekonteksti, objektin kohdekonteksti, objektiluokka ja se tietty käyttöoikeus, joka hylättiin. Lue kaikki neljä ennen teorian muodostamista, koska suorituksen hylkäys ja kirjoituksen hylkäys vaativat täysin erilaiset korjaukset.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Lähdekontekstin pitäisi vastata toimialuetta, jossa palvelu todella toimii, ja kohdekontekstin sen tiedoston tai hakemiston leimaa, johon toiminto osui. Jos jompikumpi ei täsmää sen virheen kanssa, jota jäljität, luet toista tapahtumaa.

Merkitse tietueen viereen käytännön versio ja suoritettavan tiedoston tarkka polku. Toimialueen nimi, joka esiintyy yhden jakelun käytännössä, on todiste kyseisestä asennuksesta, ei tae siitä, että toinen koonti toimittaa samat säännöt. Juuri tämä konteksti antaa jonkun toisen toistaa johtopäätöksesi omalla isännällään. Ilman sitä tietue luetaan anekdoottina eikä todisteena.

Leima, kokoonpano vai käytäntö: kolme korjausta

Ensimmäinen korjaus on leima, joka ei vastaa tiedoston asennettua sijaintia. cp:llä paikalleen kopioitu tai editorilla kirjoitettu skripti voi kantaa oletusleimaa, jota palvelun toimialue ei voi käyttää, ja odotetun kontekstin palauttaminen korjaa sen koskematta käytäntöön lainkaan.

Toinen on kokoonpano. Jakelu saattaa tarjota tuetun tavan suorittaa toiminto, dokumentoidun hakemiston apuohjelmalle tai päivitetyn käytäntöpaketin, joka jo sallii sen. Asettelusi muuttaminen tuettuun on halvempaa kuin käytännön kirjoittaminen ja kestää päivitykset.

Kolmas on todella puuttuva sääntö, ja sen pitäisi olla viimeinen keino. Luo ehdokas auditointityökaluilla, lue, mitä se todella sallii, rajaa se havaitsemaasi toimintoon ja toimialueeseen, ja anna jonkun toisen tarkistaa se ennen kuin se lähestyy tuotantoa.

Miksi vanha allow-moduuli ei ole vastaus

Tämän vian hakutulokset ovat täynnä valmiita moduuleja, usein työkalulle, jota koukku ei enää kutsu. Yhden asentaminen myöntää käyttöoikeuksia, joilla ei ehkä ole mitään tekemistä hylkäyksesi kanssa, ja se jättää todellisen epäsuhdan paikoilleen lisäten samalla pysyvän reiän.

Se myös piilottaa seuraavan epäonnistumisen. Moduuli, joka sallii laajan toimintoluokan, saa tämän virheen katoamaan ja muuttaa seuraavan paljon vaikeammin kohdennettavaksi. Moduulin poistaminen myöhemmin on myös muutos, jota kukaan ei halua aikatauluttaa, joten oikotiellä on tapana muuttua pysyväksi.

Kurinpidollinen vertailu on luettavan hylkäyksen ja ehdottamasi muutoksen välillä. Red Hatin SELinuxin vianetsintäopas asettaa leimojen ja kokoonpanon tarkistukset luodun käytännön edelle juuri tästä syystä. Jos tietueessa ei ole vastaavaa hylkäystä, SELinux ei todennäköisesti ole ongelmasi, ja polkuun, sandboxiin tai käyttöoikeuksiin liittyvät asiat ovat yhä avoinna.