- SELinux lisää Linux-ytimeen pakollisen käyttöoikeuksien hallinnan tunnisteiden ja käytäntöjen avulla, jotka menevät perinteisiä DAC-käyttöoikeuksia pidemmälle.
- Tietoturvakontekstit (käyttäjä, rooli, tyyppi, taso) ja tyyppipohjaiset käytännöt mahdollistavat erittäin tarkan käyttöoikeuksien hallinnan prosesseihin, tiedostoihin ja portteihin.
- Työkalut, kuten getenforce, chcon, semanage, semodule ja booleans, helpottavat SELinuxin käytännön hallintaa tuotannossa.
- Oikein konfiguroituna SELinux lieventää nollapäivähyökkäyksiä ja virheellisiä konfiguraatioita rajoittamalla tiukasti kunkin palvelun tai sovelluksen toimintoja.
SELinux saattaa kuulostaa kernel-nörteille varatulta teknologialta, mutta se on itse asiassa yksi tehokkaimmista Linuxin nykyisistä tietoturvatyökaluista . Jos hallinnoit palvelimia, Docker-konttien tietoturvaa , pilvi-infrastruktuuria tai jopa hieman herkkiä pöytätietokoneita, SELinuxin toiminnan ymmärtäminen tekee ratkaisevan eron yksinkertaisesti "hyvin konfiguroidun" järjestelmän ja sellaisen välillä, jota on vaikea vaarantaa, jopa nollapäivähaavoittuvuuksien varalta.
Vaikka SELinuxilla on maine "monimutkaisena", se tarjoaa hyvin loogisen mallin: se määrittelee, mitä kukin prosessi voi tehdä ja minkä objektien kanssa se voi kommunikoida, ja jos jokin poikkeaa tästä skriptistä, ydin pysäyttää sen välittömästi . Sen sijaan, että sokeasti luotettaisiin siihen, että root toimii oikein tai että daemoniesi eivät sisällä virheitä, SELinux valvoo pakollista pääsynhallintaa, joka koskee jopa superkäyttäjää, käyttäen erittäin yksityiskohtaisia tunnisteita ja käytäntöjä.
Mikä on SELinux ja minkä ongelman se ratkaisee?
Security-Enhanced Linux (SELinux) on Linux-ytimen tietoturvamoduuli, joka perustuu LSM:ään (Linux Security Modules). Sen kehitti alun perin NSA yhteistyössä Red Hatin ja muiden kumppaneiden kanssa, ja ytimen versiosta 2.6 lähtien se on ollut virallinen osa ydintä. Se ei ole erillinen sovellus, vaan ytimen laajennus, joka lisää pakollisen pääsynhallintajärjestelmän (MAC) ja roolipohjaisen pääsynhallinnan (RBAC).
Toisin kuin klassisessa Unixin harkinnanvaraisessa käyttöoikeuksien hallinnassa (DAC) – omistajan , ryhmän, muiden ja rwx-käyttöoikeudet – SELinuxissa käyttöoikeuspäätökset eivät perustu tiedoston omistajan valintaan, vaan pikemminkin tietoturvan ylläpitäjän määrittämään globaaliin käytäntöön. DAC on edelleen läsnä ja sillä on etusija: jos DAC kieltää sen, SELinux ei puutu asiaan; mutta vaikka DAC sallisikin, SELinux voi silti estää toiminnon käytäntönsä mukaisesti.
SELinux-arkkitehtuuri erottaa komponentit selvästi toisistaan: toisaalta ytimen koodin, joka tekee tietoturvapäätökset , ja toisaalta käytäntömoduulit, jotka määrittelevät, mikä on sallittua ja mikä ei. Tämä erottelu mahdollistaa sääntöjen muuttamisen ilman ytimen uudelleenkääntämistä ja virtaviivaistaa järjestelmän tietoturvaan vaikuttavien komponenttien määrää.
SELinux on otettu oletuksena käyttöön jakeluissa, kuten Fedora, Red Hat Enterprise Linux, CentOS ja Scientific Linux, ja se on myös syvästi integroitu järjestelmiin, kuten Android, jossa sitä käytetään järjestelmäprosessien ja sovellusten rajoittamiseen hyvin tietyille alueille. BSD- ja GNU/Linux-maailmassa on vaihtoehtoja, kuten AppArmor, TOMOYO ja TrustedBSD (macOS/FreeBSD:ssä), mutta SELinux erottuu edukseen tarjoamansa tarkkuuden ansiosta kaikkien järjestelmäobjektien osalta.
DAC:sta MAC:iin: miksi klassinen malli ei enää riitä
Perinteisessä Unix-järjestelmässä Domain-Object-mallia hallitaan DAC:n avulla: jokaisella tiedostolla tai resurssilla on omistaja ja käyttöoikeudet, ja mikä tahansa kyseisen käyttäjän oikeuksilla toimiva prosessi voi tehdä näillä resursseilla mitä haluaa . Tämä tarkoittaa, että jos daemon toimii root-käyttäjänä, mikä tahansa hyödynnettävissä oleva vika voi avata oven puolen järjestelmän hallintaan root-kontekstillaan.
Tyypillisiä esimerkkejä ovat tietokannat, joiden tiedostoja tulisi käsitellä vain tietokannan hallintajärjestelmän kautta, mutta jotka ovat todellisuudessa luettavissa ja muokattavissa root-UID:n omaavien prosessien toimesta ; tai kriittiset daemonit, jotka toimivat liiallisilla oikeuksilla. Ohjelmointivirhe, puskurin ylivuoto tai huono syötteen validointi voivat muuttaa palvelun valtatieksi koko järjestelmään.
SELinux lisää DAC-tason päälle pakollisen käyttöoikeuksien valvonnan (MAC) kerroksen . "Pakollinen" tarkoittaa, että järjestelmänvalvoja määrittää käyttöoikeuksien valvonnan keskitetysti käytäntöjen avulla, eivätkä käyttäjät tai prosessit voi lieventää näitä sääntöjä itse. Käyttöjärjestelmä valvoo näitä käytäntöjä arvioimalla jokaisen asiaankuuluvan ytimen toiminnon ennen sen sallimista.
Ydin tekee LSM-hookien avulla kyselyn SELinuxille jokaisesta arkaluontoisesta järjestelmäkutsusta (tiedostojen avaaminen, sokettien luominen, tiedostojärjestelmien liittäminen, IPC:n kautta kommunikointi jne.). Jokaisessa päätöspisteessä SELinux arvioi toiminnon ladatun käytännön ja kohteen ja objektin suojauskontekstin perusteella . Jos käytäntö ei nimenomaisesti myönnä lupaa, toiminto evätään riippumatta siitä, onko prosessi pääkäyttäjä vai ei.
Toimintatilat: pakottava, salliva ja poistettu käytöstä
SELinux voi toimia kolmessa selkeästi eriytetyssä toimintatilassa, jotka on tärkeää ymmärtää, jotta vältetään sekaannus tuotannossa:
- täytäntöönpanossaSELinux on käytössä ja noudattaa käytäntöä täysin. Kaikki sääntöjen vastaiset toiminnot estetään ja kirjataan lokiin.
- SallivaSELinux on aktiivinen, lataa käytännön ja nimeää tiedostojärjestelmän, mutta ei estä Se tallentaa tapahtumat vain ikään kuin ne olisi estetty. Tämä on ihanteellista virheenkorjaukseen ja käytäntöjen muokkaamiseen.
- VammaisetSELinux on poistettu käytöstä. Mitään käytäntöjä ei sovelleta eikä tunnisteita tehdä. Järjestelmä käyttää klassista DAC-mallia.
Nopeisiin ja tilapäisiin vaihtoihin valvovan ja sallivan tilan välillä käytetään komentoa `setenforce` , jossa tilaksi määritetään 0 (salliva) tai 1 (pakottava). On tärkeää tietää, että tämä muutos on pysyvä: seuraavan uudelleenkäynnistyksen jälkeen tila palautuu asetuksissa määritettyyn tilaan.
Jos tarvitset pysyvän muutoksen, sinun on muokattava tiedostoa. /etc/selinux/config (tai /etc/sysconfig/selinux joissakin jakeluissa) ja säädä direktiivin arvoa SELINUX=disabled|permissive|enforcingMuutokset tulevat voimaan seuraavan käynnistyksen yhteydessä ja monissa tapauksissa ne edellyttävät tiedostojärjestelmän uudelleennimeämistä.
Aktiivisen tilan tarkistamiseen voit käyttää komentoja, kuten getenforce tai sestatus . Ensimmäinen palauttaa yksinkertaisesti arvon Enforcing, Permissive tai Disabled; jälkimmäinen antaa kattavamman yhteenvedon SELinuxin tilasta, ladatuista käytännöistä ja aktiivisista moduuleista.
Suojauskontekstit ja merkintäjärjestelmä
SELinuxin ydin on sen suojaustunnisteiden eli kontekstien järjestelmä . Jokaisella tiedostolla, prosessilla, verkkoportilla, soketilla, laitteella jne. on siihen liittyvä konteksti, joka kuvaa, miten sitä voidaan käyttää. Tämä konteksti koostuu useista kentistä, jotka yhdessä muodostavat SELinuxin näkemyksen kyseisestä objektista.
Kontekstin yleinen muoto on user_u:role_r:type_t:level , jossa on joitakin vivahteita riippuen käytännöstä (etenkin jos käytetään MLS/MCS:ää). Jokaisella kentällä on tietty tarkoitus: SELinux-käyttäjä, rooli, tyyppi (jota kutsutaan myös toimialueeksi prosesseihin viitattaessa) ja herkkyystaso tai kategoria.
Käytännössä kriittisin elementti on tyyppi (kolmas kenttä), koska valtaosa käytäntösäännöistä muotoillaan tyyppien välisinä suhteina . Esimerkiksi httpd_t-tyypin prosessien salliminen käyttää httpd_sys_content_t-merkittyjä tiedostoja tai tietyn toimialueen salliminen kommunikoida http_port_t-merkittyjen sokettien kanssa.
Nämä kontekstit tallennetaan muodossa laajennetut tiedostojärjestelmän ominaisuudetSiksi on tärkeää käyttää tiedostojärjestelmiä, jotka tukevat xattr-tiedostoja (kuten ext4, XFS jne.). Prosessien tapauksessa nykyinen konteksti ja muut siihen liittyvät kontekstit paljastetaan pseudo-tiedostojärjestelmän kautta. /proc/<pid>/attr/ tiedostoissa, kuten current, exec, fscreate, prev, sockcreate tai keycreate.
Tyypillisiä esimerkkejä kohdennetun politiikan mukaisen järjestelmän konteksteista ovat:
- system_u:object_r:httpd_sys_content_t:s0 Apachen tai Nginxin tarjoamalle verkkosisällölle.
- system_u:object_r:home_user_t:s0 käyttäjien kotihakemistoille.
- system_u:system_r:httpd_t:s0 itse web-palvelimen suoritusalueelle.
SELinux-kontekstin komponenttien erittely
Kun kohtaat kontekstin, kuten unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 , se saattaa vaikuttaa hieroglyfeiltä, mutta jokainen osa vastaa tiettyä SELinuxin käsitettä ja sen viittauspolitiikkaa.
El SELinux-käyttäjä (sopimuksen mukaan päätteellä) _uTämä ei ole sama kuin Unix-käyttäjä tiedostossa /etc/passwd. SELinux ylläpitää omaa käyttäjätietokantaa ja yhdistää ne Linux-käyttäjiin. SELinux-käyttäjä voi ryhmitellä useita Unix-käyttäjiä, koska ajatuksena on, että MAC-kerros on riippumaton DAC:sta.
El SELinux-rooli (jälkiliitteellä _rTämä määrittää, mitä rooleja käyttäjä tai toimialue voi omaksua. Jos sitä käytetään tarkasti, sitä kutsutaan täydeksi RBAC:ksi. Useimmat tiedosto-objektit käyttävät object_r-roolia, kun taas roolit, kuten system_r, user_r, staff_r tai sysadm_r, sovelletaan prosesseihin niiden omaksuttavan tietoturvakontekstin mukaan.
El SELinux-tyyppi tai -verkkotunnus (pääte _tKäytännössä tyyppi on ratkaiseva elementti. Tyyppi kuvaa objektin luokkaa tai prosessin suoritusaluetta. Käytäntö määrittää, mitkä vuorovaikutukset tyyppien välillä ovat sallittuja: mitkä alueet voivat lukea, kirjoittaa, suorittaa tai kommunikoida minkäkin muun tyyppisten objektien kanssa.
Tasoja ja luokkia käytetään, kun monitasoinen suojaus (MLS) tai monikategoriainen suojaus (MCS) on käytössä. Luottamuksellisuudet ovat hierarkkisia (esim. s0, s1 jne.), kun taas luokat eivät ole (c0, c1, c2, ...). Erittäin kriittisissä ympäristöissä – esimerkiksi tietyissä valtion organisaatioissa – niitä käytetään varmistamaan, että tietoja voidaan lukea ja kirjoittaa vain samalle tasolle tai ylöspäin , ja eristämään tiedot hyvin tiettyjen osastojen mukaan.
SELinux-käytännöt: kohdennetut, tiukat, MLS/MCS ja modulaarisuus
SELinuxin valvoma tietoturva määräytyy ladatun käytännön mukaan . Käytäntö on yksinkertaisesti suuri joukko sääntöjä, jotka kuvaavat, mitkä verkkotunnukset voivat tehdä mitä millekin tyypeille, sekä muita elementtejä (siirtymät, merkintäsäännöt jne.). Jakelupaketit yleensä sisältävät vakiokäytäntöjä, joten sinun ei tarvitse kirjoittaa kaikkea alusta alkaen.
Yleisintä käytäntöä kutsutaan kohdennetuksi käytännöksi . Tässä tilassa vain tietyt prosessit – pääasiassa verkkopalvelut ja korkean riskin daemonit, kuten Apache, Nginx, DNS, välityspalvelimet, SNMP, syslog jne. – toimivat rajoitetuilla verkkotunnuksilla. Kaikki muut käyttäjäprosessit toimivat "rajoittamattomilla" verkkotunnuksilla, joissa käytetään olennaisesti Linuxin vakiosuojausta ja tiettyjen toimien lokikirjausta.
On myös olemassa tiukka käytäntö , jossa käytännössä kaikki prosessit on rajoitettu tietyn käytännön alle. Se on paljon turvallisempi, mutta sitä voi olla myös huomattavasti vaikeampi ylläpitää, jos mallia ei ymmärretä hyvin, koska kaikki eroavaisuudet merkinnöissä tai säännöissä voivat häiritä vakiotyönkulkuja.
Korkean turvallisuuden ympäristöissä on olemassa MLS/MCS (Multi-Level/Multi-Category Security) -käytäntöjä , jotka hyödyntävät herkkyyksiä ja luokkia entistä tarkempien valvontatoimien aikaansaamiseksi. Nämä ovat tyypillisiä erittäin jäykille sotilaallisille tai hallinnollisille ympäristöille, ja niitä käytetään harvoin tiettyjen kontekstien ulkopuolella niiden suuren operatiivisen monimutkaisuuden vuoksi.
Nykyaikaiset käytännöt jaetaan modulaarisella tavalla . Yhden monoliittisen käytäntötiedoston sijaan käytetään erillisiä moduuleja tietyille palveluille, mikä yksinkertaistaa hallintaa ja päivityksiä huomattavasti. Näitä moduuleja hallitaan työkaluilla, kuten semodule ja semanage module , joiden avulla voit asentaa, poistaa, ottaa käyttöön tai poistaa käytöstä käytännön osia ilman, että koko käytäntöä tarvitsee kääntää uudelleen joka kerta.
Miten SELinux päättää: subjektit, objektit, luokat ja käyttöoikeudet
Kun prosessi (kohde) yrittää käyttää resurssia (objektia), SELinux esittää käsitteellisesti kysymyksen: "Voiko tyypin X toimialue suorittaa operaation Y tyypin Z objektille, joka kuuluu luokkaan C?" . Vastausta etsitään sitten käytännöstä määriteltyjen sääntöjen avulla.
Useimpien jakeluiden ja Androidin käyttämissä Type Enforcement (TE) -käytännöissä jokainen objekti kuuluu luokkaan ( file, dir, fifo_file, tcp_socket, process jne.), ja käytäntö määrittää, mitkä käyttöoikeudet ovat mahdollisia kullekin luokalle: read, write, execute, bind, connect, getattr, open ja long jne.
TE-säännöt ilmaistaan hyvin suoraan. Yksi esimerkki olisi:
salli httpd_t http_port_t:tcp_socket nimi_sidonta;
Tämän säännön avulla käytäntö määrittää, että httpd_t-verkkotunnuksen prosessit voivat suorittaa name_bind-operaation TCP-soketeille, joiden tunniste on http_port_t. Lähestymistapa keskittyy objektityyppeihin ja luokkiin, ei tiettyihin polkuihin , mikä estää yllätykset tiedostoja siirrettäessä tai hakemistorakenteita muutettaessa.
Esimerkiksi Androidissa SELinux-attribuutteja käytetään ryhmittelemään tyyppejä yleisempien tunnisteiden, kuten `appdomain` , alle , jotta yksi sääntö voi koskea useita verkkotunnuksia (`untrusted_app`, `isolated_app` jne.) toistamatta määritelmiä. Makroja, kuten `rw_file_perms`, käytetään myös useiden yleisten tiedostojen käyttöoikeuksien ryhmittelyyn ja virheistä johtuvien virheiden vähentämiseen.
Sisäiset tilat, AVC ja hylkäysrekisteri
Kun käyttöoikeuspyyntö tapahtuu, SELinux tarkistaa ensin Access Vector Cache (AVC) -välimuistin, joka tallentaa viimeisimmät käyttöoikeuspäätökset prosessin nopeuttamiseksi. Jos päätös on jo välimuistissa, sitä käytetään suoraan; muussa tapauksessa palomuuri (SELinuxin sisäinen osa ytimessä) pyydetään, ja se arvioi toiminnon käytännön sekä kohteen ja objektin kontekstin perusteella.
Jos ei ole sääntöä, joka nimenomaisesti sallii pyydetyn toiminnon, oletusarvoinen päätös on hylkäys . Tämä "hylkää oletusarvoisesti" -filosofia on yksi SELinuxin kulmakivistä ja se antaa sille kestävyyden sallivia määritysvirheitä vastaan.
Kun valvontatilassa tapahtuu kielto, ydin kirjaa lokiin viestin tyyppiä avc: evätty järjestelmälokeissa. Jakelusta riippuen se saattaa näkyä /var/log/audit/audit.logja /var/log/messages tai auditd-daemon voi tallentaa ne. Nämä viestit sisältävät prosessikontekstin (scontext), objektikontekstin (tcontext), luokan, pyydetyn toiminnon ja muita virheenkorjauksessa erittäin hyödyllisiä tietoja.
Sallivassa tilassa toiminto on sallittu, mutta tapahtuma "avc: denied" generoidaan silti ja se on merkitty permissive=1:llä. Tämä on puhdasta kultaa käytäntöjen rakentamiseen ja muokkaamiseen, koska sen avulla voit nähdä, mikä rikkoisi järjestelmän, jos valvonta toteutettaisiin keskeyttämättä normaalia toimintaa.
SELinuxin integrointi jakeluihin ja Androidiin
Linux-palvelin- ja työpöytäympäristössä SELinux on oletusarvoisesti käytössä Fedora, RHEL, CentOS ja johdannaisetDebian ja Ubuntu tarjoavat täyden tuen ytimissään ja paketeissaan, vaikka aktivointi on yleensä valinnaista ja vaatii sellaisten pakettien kuin selinux-basics, selinux-policy-default ja auditd asentamisen, jota seuraa globaali uudelleentunnistus fixfiles relabel.
Android sisällytti SELinuxin alun perin versioon 4.3 sallivassa tilassa, siirtyi osittaiseen käyttöön versiossa 4.4 (vain kriittisille alueille, kuten installd, netd, vold ja zygote), ja se on ollut täysin integroitu Android 5.0:sta lähtien . Androidin käytäntö keskittyy sovellusten, järjestelmäpalveluiden ja arkaluontoisten prosessien eristämiseen tyyppien ja attribuuttien avulla, tavoitteena minimoida tietomurron vaikutus näihin komponentteihin.
Android käyttää käsitteitä, kuten untrusted_app-tyyppiä yleisille sovellusprosesseille, appdomain-attribuutteja sovellusten verkkotunnusten ryhmittelyyn ja MLS/MCS-luokkia eristääkseen tietoja sovellusten ja fyysisten käyttäjien välillä. Kaikki tämä toimii yhdessä estääkseen vaarantuneen sovelluksen pääsyn hiekkalaatikkoonsa, vaikka sillä olisi erittäin laajat käyttöoikeudet.
Tärkeää: Android yksinkertaistaa SELinux-mallia jättämällä käyttäjät, roolit ja edistyneet herkkyydet huomiotta. SELinux-käyttäjiä on vain yksi (u), kaksi perusroolia (r kohteille ja object_r objekteille), ja herkkyys on aina s0. Luokat ratkaisevat datan eristämisen.
Vertailu AppArmorin ja muiden LSM-alustojen kanssa
Monissa keskusteluissa vertailu SELinuxin ja AppArmorin välillä nousee väistämättä esiin , koska molemmat ovat Linuxin tietoturvamoduuleja ja tarjoavat MAC-osoitteita. Niiden lähestymistavat ovat kuitenkin melko erilaisia, ja tämä kannattaa ymmärtää ennen kuin valitset jommankumman omaan ympäristöösi.
SELinux määrittelee käytännön, joka keskittyy objekteihin ja niiden tyyppeihin: jokaiselle järjestelmän objektille (tiedostot, prosessit, soketit, portit, laitteet, IPC:t jne.) on määritetty tunniste. Käyttöpäätökset tehdään kohteen ja objektin kontekstin perusteella riippumatta tarkasta tiedostopolusta. Tämä tekee järjestelmästä vakaamman hakemistorakenteen muutosten tai vaihtoehtoisten tiedostojärjestelmänäkymien (chroot, säilöt, bind mounts jne.) edessä.
AppArmor puolestaan soveltaa tehtäväkeskeistä , polkuihin perustuvaa käytäntöä. Se määrittää profiilit kullekin ohjelmalle ja määrittää, mitä tiedostopolkuja, portteja jne. se voi käyttää ja millä käyttöoikeuksilla. Sen konfigurointi on intuitiivisempaa ja yleensä käyttäjäystävällisempää järjestelmänvalvojille, jotka eivät halua SELinux-asiantuntijoiksi, mutta sen hallinta on jonkin verran vähemmän yksityiskohtaista ja enemmän riippuvainen tiedostojärjestelmän rakenteesta.
Molemmissa on sama periaate, että esto tehdään oletuksena, mutta ne soveltavat sitä eri tavoin: AppArmor estää oletuksena vain ne tehtävät, jotka se kattaa profiileilla, kun taas SELinux laajentaa tiukassa tilassa ollessaan sen koko järjestelmään ja kaikkiin merkittyihin objekteihin. Tämän seurauksena SELinux tarjoaa tyypillisesti syvemmän rajoitustason laajemman ja monimutkaisemman käytännön hinnalla.
Käytännön työkaluja SELinuxin hallintaan
SELinuxin kanssa työskentely perustuu sarjaan komentorivityökaluja, jotka yksinkertaistavat tilojen, tagien, totuusarvojen ja käytäntömoduulien hallintaa. Vaikka tämä saattaa aluksi tuntua ylivoimaiselta arsenaalilta, muutamat apuohjelmat kattavat useimmat päivittäiset tehtävät.
Voit tarkastella tiedostojen ja prosessien suojauskontekstia käyttämällä vaihtoehtoa -Z yleisissä komennoissa, kuten ls, ps tai id. Esimerkiksi ls -Z DAC-oikeuksien lisäksi se näyttää kunkin tiedoston SELinux-kontekstin, jolloin voit nopeasti tarkistaa, onko merkinnät odotetun mukaisia.
Komennolla `chcon` ("change context") voit muokata manuaalisesti koko tiedoston kontekstia tai vain tiettyjä osia (rooli, tyyppi, alue) käyttämällä valitsimia, kuten `-r`, `-to` ja `-l`. Se on hyödyllinen kertaluonteisiin korjauksiin, mutta on tärkeää muistaa, että muutoksesi saattavat kadota, jos nimeäminen tehdään uudelleen käytännön mukaisesti työkaluilla, kuten `restorecon` tai `fixfiles`.
Semanage- työkalu on ajonaikaisen käytäntöjen hallinnan veitsi. Erilaisten alikomentojen avulla voit hallita pysyviä tiedostokonteksteja (fcontext), Linux- ja SELinux-käyttäjien välisiä kirjautumismäärityksiä (login), SELinux-käyttäjiä ja heidän roolejaan (user), merkittyjä portteja (port), totuusarvoja ja jopa käytäntömoduuleja. Kaikki tämä ilman, että koko käytäntöä tarvitsee kääntää uudelleen lähdekoodista.
Totuusarvojen – pienten kytkimien, jotka ottavat käyttöön tai poistavat käytöstä sääntölohkoja käytännön sisällä – tilan tarkistamiseen ja muuttamiseen käytetään getsebool- ja setsebool- parametreja itse setsebool-totuusarvo-arvon lisäksi . Tyypillinen totuusarvo on httpd_enable_homedirs, joka aktiivisena ollessaan sallii web-palvelimen käyttää käyttäjien kotihakemistoja (hyödyllinen kohteelle ~user/public_html/).
Lopuksi, komennot, kuten fixfiles, mahdollistavat tiedostojärjestelmän täydellisen uudelleennimeämisen pakottamisen määriteltyjen sääntöjen mukaisesti, ja semodule huolehtii viitekäytännön tai järjestelmänvalvojan pakkaamien ja jakamien käytäntömoduulien (.pp) asentamisesta, listaamisesta, käyttöönotosta tai poistamisesta käytöstä.
Mukautettujen käytäntöjen luominen ja mukauttaminen
Kun sovelluksella ei ole omaa SELinux-moduulia tai tarvitset tarkempaa rajoitusta, on aika ryhtyä toimeen ja luoda mukautettuja käytäntöjä . Se saattaa kuulostaa monimutkaiselta, mutta työnkulku on varsin hyvin määritelty, jos noudatat tiettyjä vaiheita huolellisesti.
Ensimmäinen vaihe on varmistaa, että asiaankuuluvat objektit (suoritettavat tiedostot, datahakemistot, soketit jne.) on merkitty oikeilla tyypeillä. Tämä voidaan saavuttaa määrittelemällä tiedostokontekstisäännöt ` semanage fcontext`- metodilla ja soveltamalla niitä `restorecon`-metodilla käyttäen säännöllisiä lausekkeita koko hakemistopuiden kattamiseksi.
Järjestelmä asetetaan sitten tyypillisesti sallivaan tilaan kyseiselle koneelle (tai joissakin tapauksissa tietylle toimialueelle) ja sovelluksen annetaan toimia normaalisti, kun taas SELinux kirjaa lokiin kaikki ` avc: denied`-lausekkeet , jotka olisivat tapahtuneet. Näitä lokeja, joita yleensä analysoidaan työkaluilla, kuten audit2allow , käytetään ehdokassääntöjen poimimiseen.
Viitekäytännöt on tyypillisesti jaettu kolmeen tiedostoon sovellusta kohden: .te-tiedostoon, joka sisältää TE-säännöt (allow, type, domain_type jne.), .fc-tiedostoon, joka sisältää tiedostokontekstisäännöt, ja .if-tiedostoon, joka sisältää julkisia rajapintoja, joita muut moduulit voivat käyttää uudelleen. Kaikki tämä käännetään .pp-moduuleiksi käyttämällä make-komentoa ja ladataan semodule-komennolla.
On erittäin tärkeää, ettei kaikkeen audit2allow'n ehdottamiin sääntöihin luoteta sokeasti: se on yleensä sallivampi kuin on ehdottoman välttämätöntä . Ihannetapauksessa ehdotetut säännöt tulisi tarkistaa manuaalisesti, luoda tarvittaessa uusia tyyppejä arkaluonteisten tietojen erottamiseksi epäolennaisista ja, kun estetty toiminto ei ole kriittinen, harkita dontaudit-sääntöjen käyttöä kohinan tallentamisen lopettamiseksi ilman oikeuksien myöntämistä.
Ympäristöissä, kuten SUSE Linux Micro tai Android, on saatavilla lisätyökaluja (esimerkiksi Udica, jolla luodaan säilökäytäntöjä JSON-kuvauksista), jotka automatisoivat osan prosessista mukauttamalla käytännön nopeasti tiettyihin säilöihin ilman, että koko käytäntökieltä tarvitsee opetella alusta alkaen.
Tämä kontekstien, modulaaristen käytäntöjen, totuusarvojen ja hallintatyökalujen ekosysteemi tekee SELinuxista erittäin vankan ja joustavan tietoturva-alustan . Pienillä alkuinvestoinneilla oppimiseen se mahdollistaa kunkin palvelun tai sovelluksen toimintojen erittäin tarkan rajoittamisen, mikä vahvistaa merkittävästi järjestelmän hyökkäyspintaa hyökkäyksiä, haittaohjelmia ja inhimillisiä virheitä vastaan.
