Wortel in 'n terminaal, geweier onder SELinux: waarom die haak misluk

Jy voer die op-skrip as wortel uit, dit voltooi, en dieselfde skrip misluk wanneer die diens dit oproep. Niks aan die lêertoestemmings het verander nie, so die natuurlike volgende stap is om hulle weer te verslap, wat niks oplos nie. Op 'n SELinux-gasheer is die deurslaggewende faktor dikwels nie wie die proses is nie, maar in watter domein dit hardloop, en wortel binne 'n beperkte domein bly beperk.

Dieselfde opdrag, twee verskillende sekuriteitsdomeine

Tipe-afdwinging evalueer die brondomein, die teikenetiket en die versoekte bewerking saam. Jou terminaalsessie hardloop in 'n onbeperkte of administratiewe domein, en die daemon hardloop in watter domein sy eenheid ook al toegewys is. Identiese opdragte lewer dus verskillende besluite, en die verskil is doelbewus eerder as 'n fout in die beleid.

Dit is waarom die vergelyking van die twee lopies net nuttig is as jy hulle kontekste vergelyk. Voer dieselfde opdrag vanuit die skulp en vanuit die haak uit, en die skulpweergawe bewys dat die binêre lêer bestaan en die argumente reg is; dit bewys niks oor of die diens toegelaat word om dit uit te voer nie. Voer dit albei maniere uit en vergelyk die domeine, nie net die uitgangskodes nie. Daardie vergelyking is wat 'n vae toestemmingsklag omskakel in 'n spesifieke vraag oor een domein en een etiket.

Die klassieke vorm van hierdie fout is 'n helper wat 'n eksterne hulpmiddel oproep. Die haak self mag toegelaat word, terwyl die hulpmiddel wat dit oproep 'n etiket dra wat die diensdomein nie mag uitvoer nie, of skryf na 'n gids waarvan die etiket dit verbied.

Lees die AVC-rekord langs die haakfout

'n AVC-weiering noem die velde wat die saak beslis: die bronkonteks van die proses, die teikenkonteks van die objek, die objekklas en die spesifieke toestemming wat geweier is. Lees al vier voordat jy 'n teorie vorm, want 'n weiering op uitvoering en 'n weiering op skryf het heeltemal verskillende herstellings.

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

Die bronkonteks behoort te pas by die domein waarin die diens werklik hardloop, en die teikenkonteks behoort te pas by die etiket van die lêer of gids wat die bewerking geraak het. As enige van die twee nie ooreenstem met die fout wat jy agtervolg nie, lees jy 'n ander gebeurtenis.

Let op die beleidweergawe en die presiese uitvoerbare pad langs die rekord. 'n Domeinnaam wat in een verspreiding se beleid voorkom, is bewyse oor daardie installasie, nie 'n waarborg dat 'n ander bou dieselfde reëls lewer nie. Daardie konteks is wat iemand anders in staat stel om jou gevolgtrekking op hul eie gasheer te herhaal. Sonder dit lees die rekord soos 'n anekdote eerder as bewyse.

Etiket, konfigurasie of beleid: drie herstellings

Die eerste herstelling is 'n etiket wat nie by die lêer se geïnstalleerde ligging pas nie. 'n Skrip wat met cp in plek gekopieer of deur 'n redigeerder geskryf is, kan 'n versteketiket dra wat die diensdomein nie kan gebruik nie, en die herstel van die verwagte konteks los dit op sonder om die beleid hoegenaamd te raak.

Die tweede is konfigurasie. Die verspreiding mag 'n ondersteunde manier bied om die bewerking uit te voer, 'n gedokumenteerde gids vir die helper, of 'n bygewerkte beleidspakket wat dit reeds toelaat. Om jou uitleg na die ondersteunde een te verander, is goedkoper as om beleid te skryf en oorleef opdaterings.

Die derde is 'n werklik ontbrekende reël, en dit behoort die laaste uitweg te wees. Genereer 'n kandidaat met die oudithulpmiddels, lees wat dit werklik toelaat, vernou dit tot die bewerking en domein wat jy waargeneem het, en laat iemand anders dit hersien voordat dit enigsins naby produksie kom.

Waarom 'n ou toelaatmodule nie die antwoord is nie

Soekresultate vir hierdie fout is vol voorafgeboude modules, dikwels vir 'n hulpmiddel wat die haak nie meer oproep nie. Om een te installeer verleen toestemmings wat dalk niks met jou weiering te doen het nie, en dit laat die werklike wanverhouding in plek terwyl dit 'n permanente gat byvoeg.

Dit verberg ook die volgende mislukking. 'n Module wat 'n breë klas bewerkings toelaat, sal hierdie fout laat verdwyn en die volgende een in iets veel moeiliker om toe te skryf verander. Om die module later te verwyder is ook 'n verandering wat niemand wil beplan nie, so die kortpad word geneig om permanent te word.

Die gedissiplineerde vergelyking is tussen die weiering wat jy kan lees en die verandering wat jy voorstel. Red Hat se SELinux-probleemoplossingsriglyne plaas etikettering- en konfigurasiekontroles voor gegenereerde beleid juis om hierdie rede. As daar geen ooreenstemmende weiering in die rekord is nie, is SELinux waarskynlik nie jou probleem nie, en pad-, sandbox- of toestemmingskwessies is steeds oop.