root во терминал, одбиен под SELinux: зошто 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 или дозволите остануваат отворени.