Pse zhvendosja e një certifikate VPN thyen etiketën e saj SELinux

Certifikatat mund të qëndrojnë në drejtorinë e duhur me një mënyrë të lexueshme dhe pronësi root, dhe shërbimi gjithsesi mund të raportojë se nuk mund ta hapë skedarin. Në një sistem SELinux, ai kombinim tregon një mekanizëm të caktuar dhe jo lejet. Etiketa udhëtoi me skedarin, sepse riemërtimi nuk krijon një objekt të ri. Inodi ruajti kontekstin e sigurisë që kishte në shtegun e vjetër, dhe politika për shtegun e ri nuk pati kurrë rastin të caktojë të vetin.

Çfarë bën në të vërtetë riemërtimi me një etiketë

Një skedar mban kontekstin e tij SELinux si të dhëna atributi të bashkangjitura inodit. Riemërtimi brenda një sistemi skedarësh ndryshon hyrjen e drejtorisë dhe asgjë tjetër, gjë që është e shpejtë dhe atomike, dhe është arsyeja pse konteksti i mbijeton zhvendosjes. Asnjë politikë nuk konsultohet, asnjë vlerë e paracaktuar nuk zbatohet dhe asnjë paralajmërim nuk shtypet.

Kopjimi sillet ndryshe. Një kopje krijon një inod të ri në drejtorinë e destinacionit, dhe politika cakton një kontekst sipas llojit të asaj drejtorie, kështu që një certifikatë e kopjuar zakonisht përfundon me etiketën e duhur, ndërsa një e zhvendosur mbetet e gabuar. Pikërisht ky ndryshim i vetëm shpjegon pjesën më të madhe të konfuzionit në këtë klasë biletash.

Zhvendosjet midis sistemeve të skedarëve kthehen në semantikën e kopjimit, kështu që i njëjti komandë mund të sillet ndryshe në dy makina në varësi të faktit nëse /etc jeton në vëllimin e vet. Kontrollojeni këtë përpara se të konkludoni se mjeti nuk është i besueshëm. Një vështrim në tabelën e montimit ju tregon çfarë lloj zhvendosjeje kryet.

Lexoni etiketën aktuale kundrejt asaj të pritur

Tre komanda vetëm-lexim i përgjigjen pyetjes pa ndryshuar asgjë. E para tregon çfarë ka skedari tani, e dyta raporton çfarë pret politika për atë shteg të saktë, dhe e treta liston çdo skedar nën drejtori, etiketa e të cilit ndryshon.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Ai që duhet besuar është ekzekutimi i thatë, sepse emërton çdo skedar, konteksti i të cilit largohet nga politika dhe gjithsesi e lë sistemin të paprekur. Nëse certifikata shfaqet në atë listë, keni gjetur mospërputhjen midis asaj që do të thotë shtegu dhe asaj që pretendon skedari. Nëse nuk shfaqet, etiketa është tashmë ajo që dëshiron politika, dhe koha juaj i takon diku tjetër.

Më pas lidhni ndryshimin me një refuzim real. Mospërputhja është provë e një etikete të gabuar, jo provë se shërbimi dështoi për shkak të saj, dhe një korrigjim i zbatuar pa një refuzim përkatës në regjistër është një hamendje me hapa shtesë.

Riktheni hartëzimin në vend që të shpikni një përjashtim

Për një vendndodhje standarde politika e harton tashmë shtegun, kështu që restorecon e zbaton dhe puna mbaron. Mbajeni shtrirjen në drejtorinë që po riparoni; rietiketimi i të gjithë sistemit të skedarëve është i ngadaltë, shqetësues, dhe e varros gabimin origjinal nën një ndryshim shumë të madh.

Për një drejtori të personalizuar rendi ka rëndësi, dhe përmbysja e tij prodhon një komandë që raporton sukses pa ndryshuar asgjë. Hartëzimi i përket politikës, rietiketimi i përket fundit, dhe ekzekutimi i thatë i përket para të dyjave. Anashkalimi i asaj pjese të fundit është mënyra se si një shteg që nuk ishte kurrë i gabuar rietiketimet gjithsesi.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon zbaton një hartëzim; nuk mund të shpikë një. Nëse asnjë rregull nuk e përshkruan shtegun, nuk ka nga të rikthehet, prandaj hartëzimi i vazhdueshëm duhet të ekzistojë para rietiketimit. Shënoni cila konfigurim zotëron atë hartëzim, sepse përndryshe një zhvendosje e mëvonshme, një përditësim pakete ose një rietiketim rikrijojnë defektin dhe personi tjetër nis nga zeroja.

Pse chcon nuk është zgjidhja

chcon shkruan një kontekst drejtpërdrejt në skedar. Ai hyn në fuqi menjëherë dhe është opsioni më pak i qëndrueshëm i disponueshëm, sepse një rietiketim i sistemit të skedarëve e zbaton politikën përsëri dhe i hedh poshtë ndryshimet manuale pa pyetur. Skedari duket i riparuar dhe riparimi ka një datë skadimi që askush nuk e shkroi. Ajo që dëshironi në vend të kësaj është një rregull që përshkruan shtegun, në mënyrë që çdo skedar që mbërrin atje të marrë automatikisht të njëjtin trajtim.

Më keq, ai mëson mësimin e gabuar: hartëzimi themelor mungon ende, kështu që defekti kthehet javë më vonë pa një shkaktar të dukshëm dhe pa kujtimin e atij anashkalimi. Përdorni chcon vetëm si eksperiment të përkohshëm për të konfirmuar një hipotezë, më pas zëvendësojeni me një hartëzim që i mbijeton rietiketimit të radhës, dhe kontrolloni që zëvendësimi është vërtet në vend.

Kur etiketa është e saktë dhe aksesi gjithsesi dështon

Filloni me drejtoritë mëmë. Leja e kalimit kontrollohet në çdo komponent të shtegut, kështu që një certifikatë e etiketuar saktë brenda një drejtorie ku shërbimi nuk mund të hyjë mbetet e palexueshme. Si SELinux ashtu edhe leja e zakonshme duhet të lejojnë çdo hap, dhe rregullimi i njërës nuk e rregullon tjetrën.

Më pas kontrolloni identitetin e procesit dhe sandboxin e vetë shërbimit. Një njësi me sandbox kufizues mund të refuzojë aksesin në një skedar që politika do ta lejonte me kënaqësi, dhe nga rreshti i regjistrit dy shkaqet duken identike. Konfirmoni cili proces po kërkon në të vërtetë, jo ai që supozoni se po kërkon.

Mbani mend se rregullat dontaudit mund të shtypin mesazhet e refuzimit, kështu që një regjistër auditimi i zbrazët është provë e dobët dhe jo provë. Nëse politika duket e saktë dhe aksesi gjithsesi dështon, hetoni përpara se të gjeneroni një modul leje të gjerë, dhe mos e çaktivizoni SELinux për të zhdukur simptomën. Të dyja shkurtoret prodhojnë një sistem që duket se funksionon dhe një qëndrim sigurie që askush nuk mund ta përshkruajë. Një hetim i shkurtër është më i mirë se secili prej tyre.