- SELinux jõustab kohustusliku juurdepääsukontrolli poliitikate ja kontekstide põhjal, lisades traditsioonilistele Unixi õigustele kriitilise kaitsekihi.
- Tõhus konfiguratsioon eeldab failisüsteemi korralikku sildistamist, sobiva režiimi valimist (lubav/jõustav) ning tõeväärtuste ja moodulite kohandamist ilma baaspoliitikat nõrgestamata.
- SELinuxi integreerimine RHEL-i, Fedora, SUSE ja openSUSE-ga võimaldab leevendada paljude CVE-de mõju ja piirata teenuseid, nagu veebiserverid, konteinerid ja võrgudeemonid.
- Kõvendamise automatiseerimine ning logide ja tööriistade (nt audit2allow) süstemaatiline kasutamine lihtsustab SELinuxi töökorras hoidmist tootmiskeskkonnas stabiilsust ohverdamata.
Kui seadistate Linuxi serveri tootmiskeskkonnaks, on selle vaikekonfiguratsioon tavaliselt üsna avatud. See on loodud kohe pärast kasutamist ideaalselt töötama, mitte olema kindlus . Siin tulebki mängu SELinux kui peamine tugevdav komponent: see lisab juhtimiskihi, mis jätkab toimimist isegi siis, kui tüüpilised kaitsemeetmed (failiõigused, tulemüür, värskendused ) ebaõnnestuvad.
SELinux võib alguses hirmutav tunduda, aga kui selle põhitõed selgeks saada, muutub see uskumatult võimsaks tööriistaks rünnakute ohjeldamiseks, kahju piiramiseks ja selliste turvastandardite nagu CIS, PCI DSS või muude kõrge kriitilisusega standardite täitmiseks. Rakenduste normaalsele käitumisele lootmise asemel sunnib süsteem iga protsessi toimima väga kindlate piiride piires.
Mis on SELinux ja miks see on Linuxi kõvendamisel oluline?
Turvalisusega täiustatud Linux on Linuxi kerneli turvalaiendus, mis põhineb kohustuslikul juurdepääsukontrollil (MAC). Erinevalt klassikalisest Unixi valikulisest juurdepääsukontrollist (DAC), kus faili omanik otsustab, kes failile juurde pääseb, dikteerib SELinuxis reeglid keskne poliitika, mida isegi juurkasutajad ei saa ilma seda selgesõnaliselt muutmata tühistada.
See mudel tagab, et juurdepääsuotsused põhinevad turvamärgistel (kontekstidel) ja eelnevalt määratletud reeglitel , mitte ainult rwx-lubadel. Isegi kui teenus on ohustatud või sellel on liigsed õigused, saab SELinux takistada sellel tundlikele failidele juurdepääsu, teiste protsesside käivitamist või võrgus liikumist üle lubatud piiride.
SELinux ei asenda traditsioonilist DAC-i, vaid täiendab seda. Esiteks kontrollitakse standardseid Unixi õigusi ja ainult siis, kui DAC seda lubab, sekkub SELinux oma poliitika valideerimiseks . Kui DAC juba juurdepääsu blokeerib, siis SELinux ei sekku ega logi midagi, mis aitab vähendada logides esinevat müra ja säilitada jõudlust.
See kihiline lähenemine on eriti märgatav ettevõttekeskkondades , nagu Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise või openSUSE Leap , kus SELinux on integreeritud ülejäänud süsteemi turvamehhanismide ja kaasaegsete tehnoloogiatega, nagu konteinerid ja virtuaalmasinad.
Põhimõisted: SELinuxi poliitikad, kontekstid ja domeenid
SELinuxi aluseks on turvapoliitikad, mis kirjeldavad, kes mida, mille vastu ja kuidas teha saab . Selles keeles peetakse protsesse subjektideks ja süsteemiressursse (failid, kataloogid, soklid, pordid, seadmed jne) objektideks.
Kasutajate „root” või „www-data” asemel töötab SELinux järgmiste kasutajatega: domeenid ja tüübidNäiteks Apache veebiserveri protsess töötab domeenis httpd_t, samas kui kliendile edastatud failidel on selline tüüp nagu httpd_sys_content_tPoliitika määratleb, millised domeenid saavad juurde pääseda millistele tüüpidele, millistele objektiklassidele (fail, kaust, sokkel, port...) ja milliste konkreetsete õigustega (lugemine, kirjutamine, käivitamine, getattr, append jne).
Igal objektil on seotud SELinuxi kontekst , mille silt on kujul:
usuario:rol:tipo:nivel
Näiteks võiks faili märgistada kui system_u:object_r:httpd_sys_content_t:s0Kus Igapäevase haldamise kõige olulisem väli on tavaliselt tüüp (httpd_sys_content_t), mis määrab, millistele protsessidomeenidele juurdepääs lubatakse.
Praktikas töötab SELinux tuhandete reeglitega. Selle haldamise võimatuks muutmise vältimiseks on poliitikad jagatud sõltumatuteks mooduliteks, mida saab lubada, keelata või värskendada ilma hiiglaslikku monoliitset plokki uuesti kompileerimata. See on ülioluline RHEL-is, SUSE-s ja openSUSE-s, kus igal asjakohasel teenusel on tavaliselt oma poliitikamoodul.
SELinuxi töörežiimid: jõustav, lubav ja keelatud
SELinux saab töötada kolmes erinevas režiimis, mis määravad, mil määral selle reegleid süsteemile reaalajas rakendatakse :
Jõustamisrežiimis jõustab kernel poliitikat rangelt. Kõik reegleid rikkuvad toimingud blokeeritakse ja logitakse . See on soovitatav režiim tootmiskeskkonnas , kui poliitika on hästi häälestatud, sest just seal pakub SELinux tõelist kaitset.
Lubavas režiimis jätkab SELinux poliitika hindamist, kuid ei blokeeri midagi . Kõik rikkumised logitakse hoiatustena. See režiim sobib ideaalselt testimiseks, uute rakenduste juurutamiseks või reeglite peenhäälestamiseks, kuna see võimaldab teil tuvastada, mis võiks jõustamist rikkuda, ilma teenuseid katkestamata.
Keelatud režiimis on SELinux täielikult keelatud. Ühtegi poliitikat ei rakendata ja SELinuxiga seotud logisid ei genereerita. Keelatud ja aktiivse režiimi (lubav või rakendav) vahel vahetamiseks on vaja taaskäivitust, kuna kernel peab failisüsteemi sildistamiseks käivituma initsialiseeritud SELinuxi toega.
Väga mõistlik tava igas distributsioonis on alustada lubavate sätetega , vaadata üle ja parandada sildistamise ja poliitikaga seotud probleemid ning lülituda sätete jõustamisele alles siis, kui kõik on stabiilne . Selle jäädavalt keelatuna eemaldab see ühe võimsaima saadaoleva kaitsekihi.
SELinuxi integreerimine RHEL-i, Fedora, SUSE ja openSUSE-sse
Sellised distributsioonid nagu Red Hat Enterprise Linux, Fedora ja nende derivaadid lubavad SELinuxi vaikimisi , tavaliselt sihtotstarbelise poliitika abil, mis piirab peamiselt systemd ja mõnede kasutajate poolt käivitatud süsteemiteenuseid.
Lisaks eelkonfigureeritud poliitikale pakutakse RHEL-is ka mitmeid tööriistu, mis takistavad administraatoril pidevalt madala taseme reeglitega maadlemast. SELinuxi tõrkeotsingu tööriist paistab silma, analüüsides keeldumisi ja pakkudes välja konkreetseid muudatusi (näiteks tõeväärtuse aktiveerimine, konteksti parandamine või täiendava mooduli genereerimine).
Lisaks laieneb SELinux konteineritele (näiteks Podmaniga) ja virtualiseeritud keskkondadele. Sobivate siltide abil on iga konteiner või virtuaalmasin kerneli tasandil teistest isoleeritud, isegi kui käituskeskkonnas või hüperviisoris on mõni haavatavus rikutud.
SUSE ökosüsteemis sisaldab SUSE Linux Enterprise Server oma kernelis ja tööriistades SELinuxi raamistikku , kuid mitte terviklikku ametlikku poliitikat. Soovitatav lähenemisviis on luua teie keskkonnale vastav kohandatud poliitika või kasutada selliseid lahendusi nagu slemicro, kui soovite minimalistlikku hosti konteinerite või virtualiseerimise jaoks täieliku SELinuxi toega.
openSUSE Leapis on testimiseks tavaline toetuda repositooriumides (nt security:/SELinux_legacy) saadaolevatele poliitikatele , teades, et kriitilise keskkonna puhul on ideaalne ikkagi poliitika, mis on läbi vaadatud ja kohandatud spetsiaalselt juurutuse jaoks.
SELinuxi poliitikamudelid: suunatud, MLS ja miinimum
SELinux saab töötada erinevate poliitikamudelitega, mis määravad kontrolli ulatuse ja sügavuse. Kolm kõige levinumat on:
Sihtpoliitika on loodud üldiste keskkondade jaoks. See keskendub teatud teenuste (eriti võrgudeemonite) piiramisele ja jätab teised protsessid leebematesse domeenidesse või isegi piiramata. See on enamikus distributsioonides vaikevalik, kuna see loob hea tasakaalu turvalisuse ja ühilduvuse vahel.
La Mitmetasandilise turvalisuse (MLS) poliitika Lisa konteksti tundlikkuse taseme väli (s0, s1, s2, kategooriad jne) ja võimaldab liigita teave ja protsessid tasemeteksSee on loodud organisatsioonidele, kellel on väga ranged nõuded (kaitse, luure, salastatud keskkonnad), kus on oluline, kes millist andmetaset näeb või muudab.
Miinimumpoliitika on lihtsustatud variant, millel on vähem reegleid ja juhtelemente. Seda kasutatakse süsteemides, millel on piiratud turvanõuded või kus soovitakse minimaalset mõju ühilduvusele , ohverdades osa SELinuxi piiramisvõimetest.
Reaalsetes juurutustes on tavaliselt eelistatav töötada sihipäraste modulaarsete poliitikatega , kohandades moodul mooduli haaval, mida ja kuidas kaitsta, selle asemel, et proovida hallata ühte suurt monoliitset faili, mida on palju raskem hallata.
Kontekstihaldus: SELinuxi siltide vaatamine, muutmine ja taastamine
Üks SELinuxi administreerimise põhiülesandeid on tagada, et failidel, kataloogidel, protsessidel ja portidel oleks poliitika kohaselt õige kontekst . Valesti määratud kontekst võib põhjustada teenuse töötamise lakkamise või ressursi liiga suure avatuse.
Failide ja kataloogide SELinuxi konteksti kontrollimiseks aktsepteerivad paljud standardkäsklused valikut -Z. Näiteks koos ls -Z /ruta näete iga kirje kasutaja, roll, tüüp ja taseja koos ps Zaux Saate aktiivsete protsesside konteksti.
Kui poliitika on installitud ja failisüsteem on märgistatud (näiteks kasutades setfiles o fixfiles failidega file_contexts), saab iga marsruut Vaikimisi tüüp vastavalt poliitikaleKui lood uue faili juba märgistatud kataloogi, pärib see kataloogi tüübi, kuid kui teisaldad selle teisest asukohast, säilitab see oma algse sildi, mis võib põhjustada vastuolusid.
Kui failil või kataloogipuul on valed sildid, saate need parandada järgmiselt: restoreconEt taastab kontekstid poliitikas määratletud väärtustele. Võimalustega nagu -R (rekursiivne) ja -v (paljusõnaline) On lihtne näha, mis muutub. See on peaaegu kohustuslik samm enne lubavalt režiimilt jõustavale režiimile üleminekut süsteemides, mis on juba mõnda aega testitud.
Uute märgistusmustrite deklareerimiseks kasutate semanage fcontextSelle tööriistaga kirjutate poliisile, mida SELinuxi tüüp tuleb määrata kindlatele teedele või regulaaravaldisteleja seejärel rakendate need muudatused failisüsteemile restoreconNäiteks saate uue sildistada DocumentRoot Apache'st koos httpd_sys_content_t et veebiserver saaks seda oma piiratud domeeni alt lugeda.
Põhikonfiguratsioon: luba SELinux ja vali režiim
SELinuxi käitumist globaalsel tasandil kontrollitakse /etc/selinux/config, kus režiim on defineeritud (enforcing, permissive o disabled) ja kasutatav poliitika (sihipärane, mls, miinimum…).
Sellistes süsteemides nagu RHEL või Fedora tuleb sihitud poliitika tavaliselt vaikimisi lubatud ja sundrežiimisSUSE-s või openSUSE-s tuleb GRUB2 kerneli parameetreid AppArmori asemel SELinuxi laadimiseks kohandada. See hõlmab selliste valikute lisamist nagu security=selinux y selinux=1 alglaadimisreale ja genereerige GRUB-i konfiguratsioon uuesti.
Pärast SELinuxi lubamist käivitamisel ja poliitika valimist on oluline teha esialgne täielik failisüsteemi sildistamine, kasutades setfiles või samaväärseid tööriistu. See samm See võib võtta aega ja seda on kõige parem teha madala nõudluse perioodil.Kuid see on aluseks süsteemi käivitumisele ilma üllatusteta sundimisrežiimis.
Keskkondades, kus migreerite AppArmorist, on see kriitilise tähtsusega vaata failid väga hoolikalt üle file_contexts ja nende kohalikud variandidsest iga tõsine ebajärjekindlus võib takistada süsteemi käivitamist. Tehke eelnevalt varukoopia ja töötage sellega semanage fcontext Poliitika vastavusse viimine süsteemi reaalsusega on peaaegu kohustuslik.
SELinux ja CVE-d: kuidas need aitavad haavatavusi leevendada
Sellised müüjad nagu Red Hat lisavad SELinuxi oma CVE-de mõjuhinnangusse . Nende raskusastme mudel (kriitiline, oluline, mõõdukas, madal) võtab arvesse, kas haavatavust saab leevendada või vähemalt ohjeldada hästi konfigureeritud SELinuxi piirangutega.
Kriitilise kaugkoodi käivitamise haavatavuse korral tippige Log4Shell (CVE-2021-44228)Ründaja saab sisestada koodi internetist ligipääsetavasse teenusesse. Kui see teenus töötab väga piiratud SELinuxi domeeni all, on kahju tekkimise potentsiaal väiksem, sest ei ole lugemiseks luba /etc/shadowmanipuleerida tundlike andmebaasidega või süsteemis ringi liikuda väljaspool seda, mis on selle funktsiooni jaoks rangelt vajalik.
Selliste privileegide eskaleerimise haavatavuste nagu CVE-2023-4911 (Looney Tunables) korral , isegi kui ärakasutamisel õnnestub anda kasutajale DAC-tasemel kõrgemad õigused, võib poliitika ikkagi takistada võtmetoiminguid, nagu kerneli moodulite laadimine, süsteemikataloogidesse kirjutamine või teatud võrgusoklite avamine . Tulemuseks on piirang sellele, mida selle äsja saadud juurdepääsuga teha saab.
Mõõdukate haavatavuste korral (näiteks teatud Grafana probleemid), mis nõuavad ebatavalisi konfiguratsioone või mida on raske ära kasutada, toimib SELinux täiendava barjäärina, hoides ära väiksema vea eskaleerumise tõsiseks intsidendiks. Sageli blokeerib poliitika otseselt juurdepääsu, mida ärakasutamine vajaks süsteemi kahjustamiseks.
Madala mõjuga haavatavuste puhul, näiteks vigade puhul, mis põhjustavad kasutajarakenduste krahhe (näiteks redaktorites nagu vim) , ei ole SELinux tavaliselt probleemi enda ennetamisel otsustav, kuid säilitab siiski oma ohjeldava rolli, tagades, et vigane protsess ei lahku oma kontseptuaalsest liivakastist.
SELinux tegevuses: veebiserveri piiramise reaalne näide
Kujutage ette veebiserverit, mis käitab RHEL-i või Fedorat ja mis seab ohtu mitu rakendust ning on hoolimata kaitsest parandustega haavatav ühe oma komponendi kaugkäivitamise ohtude suhtes . Ilma SELinuxita saaks ründaja, kes käivitab veebiserveri kasutajana koodi, paigaldada tagauksi, lugeda volitusi või pöörduda teiste süsteemide poole.
Kui SELinux on jõustamisrežiimis ja sihtotstarbeline poliitika on hästi häälestatud, töötavad domeeni all Apache, Nginx või sarnased protsessid. httpd_tsee on õigused on piiratud failidega, millel on järgmised tüübid: httpd_sys_content_t o httpd_sys_rw_content_tja kontrollitud juurdepääs määratletud portidele ka sobiva konteksti korral.
See tähendab, et kuigi ärakasutamine lubab käskude täitmist, on ohustatud protsess See ei saa lugeda selliseid faile nagu /etc/shadow ega puuduta andmebaasi katalooge märgistatud kindlate tüüpidega (näiteks mysqld_db_t) ega avada suvalisi ühendusi teiste sisemiste teenustega, kui võrgupoliitika seda piirab.
Täieliku süsteemi kompromiteerimise asemel piiratakse sissetung veebisaidi domeeni piiridesse . Jah, see on ikkagi intsident, mida uurida, kuid potentsiaalne mõju on palju väiksem ja ründajal on palju raskem tegutseda.
Tõelised väärtused, moodulid ja tööriistad poliitikate kohandamiseks
Lisaks korrektsele sildistamisele keerleb igapäevane töö SELinuxiga tavaliselt baaspoliitika väikeste muudatuste tegemise ümber ilma seda täielikult ümber kirjutamata . Siin tulevadki mängu tõeväärtused ja kohandatud moodulid.
osa tõeväärtused SELinux Need on sisse/välja lülitid, mis muudavad juba kompileeritud poliitika käitumise osi. Näiteks saab tõeväärtus lubada või keelata FTP-serveril teatud kataloogidesse kirjutamise (näiteks allow_ftpd_anon_write) või et veebiserver algatab võrguga väljuvaid ühendusi.
koos getsebool -a o semanage boolean -l Saate need lülitid loetleda ja vaadata nende kirjeldusi. Nende jäädavaks muutmiseks kasutage setsebool -P nombre_booleano on|offkus valik -P tagab, et muudatus salvestatakse kettale ja jääb ellu ka taaskäivitamiselSee on väga mugav viis "ametliku" poliitika kohandamiseks teie serveri konkreetsete vajadustega.
Teisest küljest kasutamine poliitikamoodulid See võimaldab teil reegleid laiendada või muuta ilma baaspoliitikat puudutamata. Aktiivseid mooduleid saate vaadata semodule -lühe keelamiseks semodule -d nombre või taasaktiveerige see semodule -e nombreSUSE/openSUSE puhul on see eriti kasulik süsteemi osade peenhäälestamiseks, millele SELinuxi fookus peaks olema, samal ajal kui juurutamist stabiliseerite.
Kui teil on vaja anda väga spetsiifilisi lisalube, siis on nende kombinatsioon... audit2allow y semodule See teeb elu palju lihtsamaks. Põhineb andmetel /var/log/audit/audit.log, audit2allow näitab, milline reegel blokeeriti ja genereerib mooduli mis installimisel lubab täpselt seda, mis varem keelatud oli.
Logid, auditeerimine ja tõrkeotsing SELinuxiga
Iga kord, kui SELinux takistab toimingut, mida poliitika ei luba, AVC-keeldumine (Juurdepääsuvektori vahemälu keelamine), mis tavaliselt salvestatakse /var/log/audit/audit.logeeldusel, et teenus auditd esté funcionando.
Need kirjed sisaldavad palju teavet: mida on püütud teha (avc: denied { append }, write, getattrjne), milline protsess seda taotles (pid, comm=), millise faili või ressursi kohta (name=, dev=, ino=), milline oli algse protsessi kontekst (scontext) ja millises kontekstis sihtkoht (tcontext)Alguses tunduvad need krüptiliste ridadena, aga mõningase harjutamisega on need toimuva mõistmiseks puhas kuld.
Et vältida logi käsitsi lugemise hullumeelsust, on olemas sellised tööriistad nagu ausearch lubada filtreerimist sõnumi tüübi järgi (näiteks -m AVC) või ajutise akna abil (-ts recent). Ja ennekõike audit2allow ja kommunaalteenused, näiteks sealert aidata tõlkida need sündmused peaaegu inimkeelde ja näita soovitusi.
Tüüpiline tõrkeotsingu töövoog oleks järgmine: audit2allow -w -a Viimaste teadete selgituste nägemiseks tehke järgmist. audit2allow -a o -i fichero konkreetsete reeglite kontrollimiseks ja lõpuks otsustage, kas on mõttekas luua moodul, mis selle loa avab Või kui plokk on vastupidiselt ohutul poolel ja seda on parem mitte puutuda.
Alati, kui mooduleid genereeritakse koos audit2allow -M nombre ja on paigaldatud koos semodule -iNeid seadeid tasub üle vaadata, sest tööriist kipub olema helde ja võib anda rohkem ligipääsu kui hädavajalik. SELinux pakub ligipääsu tugevdamiseks palju paindlikkust, kuid hooletu kasutamine võib lõpuks poliitikas endas lünki tekitada.
SELinux Linuxi kõvendamise strateegia raames
SELinux ei eksisteeri vaakumis: see on integreeritud laiemasse kaitsestrateegiasse, mis hõlmab piiratud privileegidega kasutajaid, tulemüüre, SSH kaitset, jõhkra jõu vastaseid mehhanisme ja konfiguratsiooni automatiseerimist.
Pärast serveri installimist on väga levinud muster luua kasutaja piiratud sudo õigustega , et mitte kunagi töötada otsese juurkasutajana, aktiveerida võrgutulemüür (näiteks ufw või iptables/nftables) , installida tööriistad nagu Fail2ban korduvate juurdepääsukatsete blokeerimiseks ja konfigureerida SSH heade tavade järgi (mittestandardne port, juurkasutaja juurdepääsu keelamine, võtme autentimine, katsete piirangud, tugev krüptimine jne).
Sellele alusele tuginedes lisab SELinux MAC-kihi: isegi kui ründaja saab juurdepääsu valesti konfigureeritud sudo-õiguste või SSH-parooliga kasutajale, saab poliitika ikkagi piirata, millistele protsessidele ja failidele kasutaja juurde pääseb . See pole lollikindel, kuid sulgeb paljud haavatavused, mida tavaliselt ära kasutavad automatiseeritud rünnakud, mida on kirjeldatud maatriksites nagu MITRE ATT&CK.
Serverite arvu kasvades muutub kõigi nende kaitsemeetmete käsitsi rakendamine ebapraktiliseks. Siin tulevadki mängu automatiseerimis- ja orkestreerimistööriistad (Ansible, Puppet, Chef, kommertslikud automatiseeritud kaitselahendused jne), mis võimaldavad juurutada järjepidevaid SELinuxi poliitikaid, kohandada tõeväärtusi, sildistada teid ja hooldada soovitud olekuid ilma tunde masina kohta kulutamata.
Sadade sõlmedega organisatsioonides võib see automatiseerimine olla määravaks teguriks mõistlikult homogeense ja turvalise keskkonna või ebajärjekindlate konfiguratsioonide džungli loomisel, kus SELinux on pooltel serveritel keelatud, "et see kedagi ei häiriks".
Lõppkokkuvõttes, kui SELinux on hästi rakendatud – jõustamisrežiimi, järjepidevate kontekstide, muudetud poliitikate, peenhäälestatud moodulite ja jälgitavate logidega –, saab sellest omamoodi turvavõrk, mis hoiab kummalise käitumise eemal, piirab sissetungimist ja aitab näidata, et auditite, eeskirjade ja turvalisuse parimate tavade jaoks rakendatakse tugevaid juurdepääsukontrolle.
