- SELinux спроводи обавезну контролу приступа на основу политика и контекста, додајући критични слој јачања у односу на традиционалне Unix дозволе.
- Ефикасна конфигурација захтева правилно обележавање фајл система, избор одговарајућег режима (дозвољени/примењујући) и подешавање булових вредности и модула без слабљења основне политике.
- Интеграција SELinux-а са RHEL-ом, Fedora-ом, SUSE-ом и openSUSE-ом омогућава ублажавање утицаја многих CVE-ова и ограничавања сервиса као што су веб сервери, контејнери и мрежни демони.
- Аутоматизација осигурања и систематско коришћење логова и алата попут audit2allow олакшава одржавање SELinux-а оперативним у продукцији без жртвовања стабилности.

Када подешавате Linux сервер за продукцију, његова подразумевана конфигурација је обично прилично отворена. Дизајнирана је тако да Све би требало да функционише савршено из првог пута, не да буде бункер.Ту SELinux долази до изражаја као кључна компонента за јачање: додаје слој контроле који наставља да ради чак и када типичне одбране (дозволе датотека, заштитни зид итд.) откажу. исправке) не успети.
SELinux може на први поглед деловати сувопарно, али када једном схватите његове основе, постаје моћан алат за Ограничите експлоите, ограничите штету и испуните безбедносне стандарде као што су CIS, PCI DSS или окружења са високом критичношћу. Уместо да се ослања на апликације да се добро понашају, систем приморава сваки процес да ради унутар веома специфичних ограничења.
Шта је SELinux и зашто је важан за јачање Линукса?
Линукс са побољшаном безбедношћу је Безбедносно проширење језгра Линукса засновано на обавезној контроли приступа (MAC). За разлику од класичне дискреционе контроле приступа (DAC) у Јуниксу, где власник датотеке одлучује ко улази, у SELinux-у правила диктира централна политика која чак ни сами root корисници Могу се прескочити без експлицитне промене.
Овај модел значи да се одлуке о приступу доносе на основу безбедносне ознаке (контексти) и унапред дефинисана правилане само rwx дозволе. Чак и ако је сервис угрожен или има прекомерне дозволе, SELinux може да га спречи да приступа осетљивим датотекама, покреће друге процесе или се креће по мрежи ван својих овлашћених граница.
SELinux не замењује традиционални DAC, већ га допуњује. Прво, проверава стандардне Unix дозволе и, Само ако DAC дозволи операцију, SELinux улази у валидацију своје политике.Ако DAC већ блокира приступ, SELinux не интервенише нити евидентира било шта, што помаже у смањењу шума у логовима и одржавању перформанси.
Овај слојевити приступ је посебно приметан у пословна окружења као Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise или openSUSE LeapSELinux је интегрисан са осталим безбедносним механизмима система и са модерним технологијама као што су контејнери и виртуелне машине.

Кључни концепти: SELinux политике, контексти и домени
Основа SELinux-а је безбедносне политике које описују ко шта може да ради, против чега и какоУ том језику, процеси се сматрају субјектима, а системски ресурси (датотеке, директоријуми, сокети, портови, уређаји итд.) објектима.
Уместо да кориснике посматра као „root“ или „www-data“, SELinux ради са домени и типовиНа пример, процес веб сервера Apache се покреће у домену httpd_t, док датотеке које се служе клијенту имају тип као што је httpd_sys_content_tПолитика дефинише који домени могу приступити којим типовима, за које класе објеката (датотека, директоријум, сокет, порт...) и са којим специфичним дозволама (читање, писање, извршавање, преузимање података, додавање, итд.).
Сваки објекат има придружен један. SELinux контекст, ознака облика:
usuario:rol:tipo:nivel
На пример, датотека би могла бити означена као system_u:object_r:httpd_sys_content_t:s0Где Најважније поље за свакодневну администрацију је обично тип (httpd_sys_content_t), што одређује којим доменима процеса ће бити дозвољен приступ.
У пракси, SELinux ради са хиљадама правила. Да би се спречило да ово постане неуправљиво, политике су подељене на независни модули који се могу активирати, деактивирати или ажурирати без потребе за рекомпилирањем огромног монолитног блока. Ово је фундаментално у RHEL-у, SUSE-у и openSUSE-у, где свака релевантна услуга обично има свој модул политике.
SELinux режими рада: спровођење, дозвољавање и онемогућавање
SELinux може да ради у три различита режима, који одређују степен у ком Његова правила се примењују на систем у реалном времену.:
У моду спровођење (усаглашеност), језгро строго спроводи политику. Свака радња која крши правила биће Блокира и евидентира сеОво је препоручени режим за продукцију када је политика већ добро подешена, јер је то место где SELinux заиста штити.
У моду пермисивна (дозвољено), SELinux наставља да процењује политику, али Не блокира ништа.Сва кршења се евидентирају као упозорења. Овај режим је идеалан за фазе тестирања, имплементацију нових апликација или фино подешавање правила, јер вам омогућава да откријете шта би прекршило спровођење без прекида услуга.
У моду онеспособљенSELinux је потпуно онемогућен. Не примењују се никакве смернице и не генеришу се логови везано за SELinux. Пребацивање између онемогућеног и активног режима (дозвољеног или принудног) захтева поновно покретање система, јер се језгро мора покренути са иницијализованом подршком за SELinux да би могло да означи фајл систем.
Веома разумна пракса у било којој дистрибуцији је да се прво покренете пермисивнаПрегледајте и исправите проблеме са означавањем и смерницама, и то тек када је све стабилно прећи на спровођењеТрајно онемогућавање уклања један од најмоћнијих слојева заштите који су вам доступни.
Интеграција SELinux-а у RHEL, Fedora, SUSE и openSUSE
Дистрибуције попут Red Hat Enterprise Linux, Fedora и деривати подразумевано омогућавају SELinux, обично користећи циљану политику која углавном ограничава системске сервисе које покрећу systemd и неки корисници.
У RHEL-у, поред унапред конфигурисаних смерница, нуди се низ алата како администратор не би морао стално да се бори са правилима ниског нивоа. Издваја се SELinux Troubleshooter, који анализира догађаје порицања и предлаже конкретне промене (као што је активирање буловске вредности, исправљање контекста или генерисање додатног модула).
Штавише, SELinux се протеже на контејнера (на пример са Podman-ом) већ виртуелизована окружења. Са одговарајућим ознакама, сваки контејнер или виртуелна машина је изолована од осталих на нивоу језгра, чак и ако дође до цурења због интерних рањивости у runtime-у или хипервизору.
У SUSE екосистему, SUSE Linux Enterprise Server доноси SELinux фрејмворк подржан у језгру и алатимаМеђутим, не постоји свеобухватна званична политика. Препоручени приступ је изградња политике прилагођене окружењу или коришћење решења попут slemicro-а када је пожељан минималистички хост за контејнере или виртуелизацију са пуном SELinux подршком.
У openSUSE Leap-у, уобичајено је ослањање на политике доступне у репозиторијумима као што су безбедност:/SELinux_legacy за тестирање, знајући да је за критично окружење идеална и даље ревидирана политика посебно прилагођена распоређивању.
Модели политике SELinux-а: циљани, MLS и минимални
SELinux може да ради са различитим моделима политика, који одређују обим и дубину контроле. Три најчешћа су:
La циљана политика Намењен је за општа окружења. Фокусира се на ограничити одређене услуге (посебно мрежне демоне) и оставља друге процесе у дозвољенијим доменима или чак неограниченим. То је подразумевана опција у већини дистрибуција јер постиже добру равнотежу између безбедности и компатибилности.
La Политика вишеслојне безбедности (MLS) Додајте поље нивоа осетљивости у контекст (s0, s1, s2, категорије итд.) и омогућава класификујте информације и процесе у нивоеНамењен је организацијама са веома строгим захтевима (одбрана, обавештајне службе, класификована окружења) где је важно ко може да види или измени који ниво података.
La минимална политика То је смањена варијанта, са мање правила и контрола. Користи се у системима са ограничени безбедносни захтеви или тамо где се жели минималан утицај на компатибилност, жртвујући неке од SELinux-ових могућности ограничавања.
У стварним применама, обично је пожељније радити са циљане модуларне политике, подешавајући модул по модул шта је заштићено и како, уместо покушаја управљања једном огромном монолитном датотеком, коју је много теже одржавати.
Управљање контекстом: преглед, промена и враћање SELinux ознака
Један од кључних задатака у SELinux администрацији је да Уверите се да датотеке, директоријуми, процеси и портови имају исправан контекст у складу са политиком. Погрешно додељен контекст може проузроковати да сервис престане да ради или да ресурс буде превише изложен.
Да би се прегледао SELinux контекст датотека и директоријума, многе стандардне команде прихватају опцију -Z. На пример, са ls -Z /ruta можете видети корисник, улога, тип и ниво сваког уноса, и са ps Zaux Добијате контекст активних процеса.
Када је политика инсталирана и систем датотека је означен (на пример, коришћењем setfiles o fixfiles са датотекама file_contexts), свака рута добија подразумевани тип према правилимаАко креирате нову датотеку у већ означеном директоријуму, она ће наследити тип директоријума, али ако је преместите са друге локације, задржаће своју оригиналну ознаку, што може проузроковати недоследности.
Ако датотека или стабло директоријума има погрешне ознаке, можете их исправити помоћу restoreconДа враћа контексте на вредности дефинисане у политици. Са опцијама попут -R (рекурзивно) и -v (опширно) Лако је видети шта се мења. То је готово обавезан корак пре преласка са дозвољавајућег на принудни режим на системима који су већ неко време у фази тестирања.
Да бисте декларисали нове обрасце означавања, користите semanage fcontextПомоћу овог алата у политику пишете шта SELinux тип мора бити додељен одређеним путањама или регуларним изразимаа затим примењујете те промене на систем датотека помоћу restoreconНа пример, можете означити нови DocumentRoot из Апача са httpd_sys_content_t тако да веб сервер може да га прочита под својим ограниченим доменом.
Основна конфигурација: омогућите SELinux и изаберите режим
Понашање SELinux-а на глобалном нивоу је контролисано из /етц/селинук/цонфиг, где је мод дефинисан (enforcing, permissive o disabled) и политику која ће се користити (циљана, mls, минимална…).
У системима као што су RHEL или Fedora, циљана политика обично долази омогућено подразумевано и у режиму принудеУ SUSE или openSUSE, параметри језгра у GRUB2 морају бити подешени да би се учитао SELinux уместо AppArmor-а. То подразумева додавање опција као што су security=selinux y selinux=1 на линију за покретање и регенеришите GRUB конфигурацију.
Након омогућавања SELinux-а при покретању система и одабира политике, важно је извршити почетно потпуно тестирање фајл система користећи setfiles или еквивалентне алате. Овај корак То може потрајати и најбоље је то урадити током периода мале потражње.Али то је основа да се систем покрене без изненађења у режиму принудног рада.
У окружењима где мигрирате са AppArmor-а, кључно је пажљиво прегледајте датотеке file_contexts и њихове локалне варијантејер свака озбиљна недоследност може спречити покретање система. Направите резервну копију унапред и радите са semanage fcontext Усклађивање политике са реалношћу система је готово обавезно.
SELinux и CVE: како помажу у ублажавању рањивости
Продавци попут Red Hat-а укључују SELinux као фактор у својим Процена утицаја ЦНЕЊегов модел озбиљности (Критично, Важно, Умерено, Ниско) узима у обзир да ли се квар може ублажити или барем обуздати добро конфигурисаним SELinux ограничењима.
У критичној рањивости за даљинско извршавање кода, откуцајте Лог4Шел (CVE-2021-44228)Нападач би могао да убаци код у сервис доступан са интернета. Ако тај сервис ради под веома ограниченим SELinux доменом, потенцијал за штету је смањен, јер неће имати дозволу за читање /etc/shadowманипулисати осетљивим базама података или се кретати кроз систем изван онога што је строго неопходно за његово функционисање.
Код кварова ескалације привилегија, као што су CVE-2023-4911 (Луни Тјунаблс)Чак и ако експлоит омогући приступ кориснику са вишим привилегијама на DAC нивоу, политика може и даље да важи. спречавање кључних радњи као што су учитавање модула језгра, писање у системске директоријуме или отварање одређених мрежних сокетаРезултат је да је оно што се може учинити са тим добијеним приступом ограничено.
Код умерених рањивости (на пример, одређени проблеми у Grafana-и) које захтевају неуобичајене конфигурације или их је тешко искористити, SELinux делује као Додатна баријера која спречава ескалацију мањег квара озбиљан инцидент. Често, политика директно блокира приступ који би експлоатацији био потребан да би утицала на систем.
Код рањивости са малим утицајем, као што су грешке које узрокују падови у корисничким апликацијама (на пример, у едиторима као што је vim)SELinux обично није пресудан у спречавању самог проблема, али и даље одржава своју улогу обуздавања, осигуравајући да неисправан процес не напусти његов концептуални „песак“.
SELinux у акцији: пример ограничења веб сервера из стварног света
Замислите веб сервер који ради на RHEL-у или Fedora-и, који открива неколико апликација и, упркос томе што је заштићен закрпама, На крају постаје рањив на експлоатацију даљинског извршавања у једној од његових компоненти. Без SELinux-а, нападач који извршава код као корисник веб сервера могао би да инсталира задња врата, чита акредитиве или прелази на друге системе.
Са SELinux-ом у режиму спровођења и добро подешеном циљаном политиком, Apache, Nginx или слични процеси се покрећу под доменом httpd_t, које има дозволе ограничене на датотеке означене типовима као што су httpd_sys_content_t o httpd_sys_rw_content_t, и контролисан приступ дефинисаним портовима такође са одговарајућим контекстом.
То значи да, иако експлоит омогућава извршавање команди, угрожени процес Не може да чита датотеке као што су /etc/shadow нити додиривати директоријуме базе података означени одређеним типовима (на пример mysqld_db_t), нити отварати произвољне везе са другим интерним сервисима ако мрежна политика то ограничава.
Уместо да се говори о потпуном компромиту система, упад остаје затворено унутар граница веб доменаДа, то ће и даље бити инцидент који треба истражити, али је плафон удара много нижи и нападачу је буквално много теже да се креће.
Булеанске вредности, модули и алати за подешавање политика
Поред правилног обележавања, свакодневни рад са SELinux-ом се обично врти око да се направе мале измене основне политике без потребе да се она потпуно преписујеОвде долазе до изражаја булове вредности и прилагођени модули.
Л Булове вредности SELinux То су прекидачи за укључивање/искључивање који мењају делове понашања већ компајлиране политике. На пример, булова вредност може дозволити или забранити FTP серверу да пише у одређене директоријуме (у случају allow_ftpd_anon_write), или да веб сервер иницира одлазне везе са мрежом.
са getsebool -a o semanage boolean -l Можете навести ове прекидаче и видети њихове описе. Да бисте их трајно променили, користите setsebool -P nombre_booleano on|offгде је опција -P осигурава да се промена сачува на диску и да преживи поновно покретање системаТо је веома згодан начин да прилагодите „званичну“ политику специфичним потребама вашег сервера.
С друге стране, употреба модули политике Омогућава вам да проширите или измените правила без додиривања основне политике. Можете да видите активне модуле помоћу semodule -lда онемогућите један са semodule -d nombre или га поново активирајте помоћу semodule -e nombreУ SUSE/openSUSE-у ово је посебно корисно за фино подешавање делова система на које желите да се SELinux фокусира док стабилизујете своје распоређивање.
Када треба да доделите веома специфичне додатне дозволе, комбинација audit2allow y semodule То чини живот много лакшим. На основу евиденције о /var/log/audit/audit.log, audit2allow вам показује које правило је блокирано и генерише модул који, ако га инсталирате, омогућава управо оно што је раније било забрањено.
Записи, ревизија и решавање проблема са SELinux-ом
Сваки пут када SELinux спречи акцију коју политика не дозвољава, Одбијање AVC-а (Одбијање кеширања вектора приступа) које се обично снима у /var/log/audit/audit.logпод условом да услуга auditd ради.
Ови уноси садрже много информација: шта је покушано да се уради (avc: denied { append }, write, getattrитд.), који је процес то захтевао (pid, comm=), на којој датотеци или ресурсу (name=, dev=, ino=), какав је контекст имао оригинални процес (scontext) и у ком контексту је одредиште (tcontext)У почетку делују као загонетне линије, али уз мало вежбе постају чисто злато за разумевање шта се дешава.
Да бисте избегли да ручно читате лог, алати попут ausearch омогућити филтрирање по типу поруке (на пример -m AVC) или привременим прозором (-ts recent). И, пре свега, audit2allow и комуналне услуге као што су sealert помоћи да се да преведе ове догађаје на готово људски језик и прикажи предлоге.
Типичан ток рада за решавање проблема би био коришћење audit2allow -w -a Да бисте видели објашњења најновијих обавештења, онда audit2allow -a o -i fichero да се провере одређена правила и коначно одлучите да ли је вредно креирати модул који откључава ту дозволу Или ако је, напротив, блок на сигурној страни и најбоље га је не дирати.
Кад год се модули генеришу са audit2allow -M nombre и инсталирани су са semodule -iВреди прегледати ова подешавања, јер алатка обично буде издашна и може да одобри више приступа него што је строго потребно. SELinux нуди велику флексибилност за осигуравање приступа, али непажљива употреба може довести до стварања рупа у самој политици.
SELinux у оквиру стратегије јачања Линукса
SELinux не постоји у вакууму: интегрисан је у ширу стратегију јачања која укључује корисници са ограниченим привилегијама, заштитни зидови, SSH ојачање, механизми против грубе силе и аутоматизација конфигурација.
Веома уобичајен образац након инсталирања сервера је креирање корисник са ограниченим sudo привилегијама да никада не ради као директни root, активирајте мрежни заштитни зид (као што је ufw или iptables/nftables)Инсталирајте алате попут Fail2ban-а да бисте блокирали поновљене покушаје пријављивања и Конфигуришите SSH користећи најбоље праксе (нестандардни порт, онемогућавање root приступа, аутентификација кључа, ограничења покушаја, робусно шифровање итд.).
На основу тога, SELinux додаје MAC слој: чак и ако нападач добије корисника са погрешно конфигурисаном sudo или SSH лозинком, Политика и даље може да ограничи које процесе и датотеке корисник може да додирне. када извршава своје радње. Није непогрешив, али затвара многа врата која аутоматизовани напади описани у матрицама као што је MITRE ATT&CK обично искоришћавају.
Како број сервера расте, ручно примењивање свих ових мера заштите постаје непрактично. Ту [следеће долази до изражаја] алати за аутоматизацију и оркестрацију (Ansible, Puppet, Chef, комерцијална решења за аутоматизовано очвршћавање, итд.) која вам омогућавају да примените конзистентне SELinux политике, подесите булове вредности, означите руте и одржавате жељена стања без трошења сати по машини.
У организацијама са стотинама чворова, ова аутоматизација може бити разлика између поседовања окружења релативно хомоген и безбедан, или џунгла недоследних конфигурација где је SELinux онемогућен на половини сервера „тако да никоме не смета“.
На крају крајева, када се SELinux правилно имплементира — са режимом спровођења, конзистентним контекстима, ревидираним политикама, фино подешеним модулима и праћеним логовима — он постаје нека врста сигурносне мреже која Контролише необично понашање, спречава упаде и помаже у демонстрирању да се примењују робусне контроле приступа. у припреми за ревизије, прописе и најбоље безбедносне праксе.
Преглед садржаја
- Шта је SELinux и зашто је важан за јачање Линукса?
- Кључни концепти: SELinux политике, контексти и домени
- SELinux режими рада: спровођење, дозвољавање и онемогућавање
- Интеграција SELinux-а у RHEL, Fedora, SUSE и openSUSE
- Модели политике SELinux-а: циљани, MLS и минимални
- Управљање контекстом: преглед, промена и враћање SELinux ознака
- Основна конфигурација: омогућите SELinux и изаберите режим
- SELinux и CVE: како помажу у ублажавању рањивости
- SELinux у акцији: пример ограничења веб сервера из стварног света
- Булеанске вредности, модули и алати за подешавање политика
- Записи, ревизија и решавање проблема са SELinux-ом
- SELinux у оквиру стратегије јачања Линукса