Root у терминалу, одбијен под SELinux-ом: зашто hook не успева
Hook који ручно ради беспрекорно може бити одбијен унутар услуге. Упоредите домен процеса, ознаку датотеке и одбијену дозволу пре измена.
Покрећете up скрипту као root, она се завршава, а иста скрипта не успева када је услуга позове. Ништа у дозволама датотеке није промењено, па је природан следећи корак да их поново олабавите, што ништа не поправља. На SELinux домаћину одлучујући фактор често није ко је процес, већ у ком домену се извршава, а root унутар ограниченог домена остаје ограничен.
Иста наредба, два различита безбедносна домена
Типско спровођење заједно оцењује изворни домен, циљну ознаку и захтевану операцију. Ваша терминална сесија се извршава у неограниченом или административном домену, а демон се извршава у домену који је додељен његовој јединици. Зато идентичне наредбе дају различите одлуке, а разлика је намерна, а не грешка у политици.
Зато је поређење два извршавања корисно само ако упоредите њихове контексте. Покрените исту наредбу из љуске и из hook-а, и верзија из љуске доказује да бинарна датотека постоји и да су аргументи тачни; она не доказује ништа о томе да ли услуга сме да је изврши. Покрените је на оба начина и упоредите домене, не само излазне кодове. Управо то поређење претвара нејасну жалбу на дозволе у конкретно питање о једном домену и једној ознаци.
Класичан облик ове грешке је помоћник који позива спољни алат. Сам hook може бити дозвољен, док алат који позива носи ознаку коју домен услуге не сме да изврши, или пише у директоријум чија ознака то забрањује.
Прочитајте AVC запис поред грешке hook-а
AVC одбијање именује поља која одлучују случај: изворни контекст процеса, циљни контекст објекта, класу објекта и конкретну одбијену дозволу. Прочитајте сва четири пре него што направите теорију, јер одбијање за извршавање и одбијање за писање имају потпуно различите поправке.
ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn
Изворни контекст треба да одговара домену у ком услуга стварно ради, а циљни контекст ознаци датотеке или директоријума којег је операција дотакла. Ако се било које од тога не поклапа са грешком коју пратите, читате други догађај.
Поред записа забележите верзију политике и тачну путању извршне датотеке. Назив домена који се појављује у политици једне дистрибуције доказ је о тој инсталацији, а не гаранција да ће друга градња испоручити иста правила. Управо тај контекст омогућава неком другом да понови ваш закључак на свом домаћину. Без њега запис се чита као анегдота, а не као доказ.
Ознака, конфигурација или политика: три поправке
Прва поправка је ознака која се не поклапа са инсталираном локацијом датотеке. Скрипта копирана на место помоћу cp или написана уређивачем може носити подразумевану ознаку коју домен услуге не може да користи, а враћање очекиваног контекста то решава без дирања политике.
Друга је конфигурација. Дистрибуција може нудити подржани начин извршавања операције, документовани директоријум за помоћника или ажурирани пакет политике који је већ дозвољава. Промена вашег распореда на подржани јефтинија је од писања политике и преживљава ажурирања.
Трећа је заиста правило које недостаје и треба да буде последње средство. Генеришите кандидата алатима за ревизију, прочитајте шта он заиста дозвољава, сузите га на операцију и домен које сте приметили, и нека га неко други прегледа пре него што се приближи продукцији.
Зашто стари allow модул није одговор
Резултати претраге за ову грешку пуни су готових модула, често за алат који hook више не позива. Инсталирање једног даје дозволе које можда немају никакве везе са вашим одбијањем, и оставља праву неусклађеност на месту док додаје трајну рупу.
Он скрива и следећи неуспех. Модул који дозвољава широку класу операција учиниће да ова грешка нестане и претворити следећу у нешто много теже за приписивање. Уклањање модула касније је такође промена коју нико не жели да планира, па пречица има тенденцију да постане трајна.
Дисциплиновано поређење је између одбијања које можете да прочитате и промене коју предлажете. Упутство Red Hat-а за решавање проблема са SELinux-ом ставља провере ознака и конфигурације испред генерисане политике управо из овог разлога. Ако у запису нема одговарајућег одбијања, SELinux вероватно није ваш проблем, и питања путање, sandbox-а или дозвола су и даље отворена.