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 или написан с редактор, може да носи етикет по подразбиране, който домейнът на услугата не може да използва, и възстановяването на очаквания контекст го поправя, без да се пипа политиката.

Втората е конфигурацията. Дистрибуцията може да предоставя поддържан начин за изпълнение на операцията, документирана директория за помощника или актуализиран пакет с политика, който вече я разрешава. Промяната на оформлението ви към поддържаното е по-евтина от писане на политика и оцелява при актуализации.

Третата е наистина липсващо правило и трябва да бъде последната мярка. Генерирайте кандидат с инструментите за одит, прочетете какво всъщност разрешава, стеснете го до операцията и домейна, които сте наблюдавали, и накарайте някой друг да го прегледа, преди да се доближи до продукция.

Защо стар модул за разрешаване не е отговорът

Резултатите от търсене за тази неизправност са пълни с готови модули, често за инструмент, който hook-ът вече не извиква. Инсталирането на един дава разрешения, които може да нямат нищо общо с вашия отказ, и оставя истинското несъответствие на място, като добавя постоянна дупка.

Той също скрива следващия провал. Модул, който разрешава широк клас операции, ще накара тази грешка да изчезне и ще превърне следващата в нещо много по-трудно за приписване. Премахването на модула по-късно също е промяна, която никой не иска да планира, затова краткият път обикновено става постоянен.

Дисциплинираното сравнение е между отказа, който можете да прочетете, и промяната, която предлагате. Ръководството на Red Hat за отстраняване на проблеми със SELinux поставя проверките на етикетите и конфигурацията преди генерираната политика точно по тази причина. Ако в записа няма съответен отказ, SELinux вероятно не е вашият проблем и проблемите с пътя, sandbox или разрешенията все още са открити.