Защо преместването на VPN сертификат чупи етикета SELinux

Сертификатите могат да стоят в правилната директория с четим режим и собственост на root, а услугата все още да съобщава, че не може да отвори файла. В система със SELinux тази комбинация сочи към един конкретен механизъм, а не към права. Етикетът пътува с файла, защото преименуването не създава нов обект. Inode-ът запази контекста за сигурност, който имаше на стария път, а политиката за новия път така и не получи шанс да зададе своя.

Какво всъщност прави преименуването с етикета

Файлът носи своя контекст на SELinux като данни от атрибути, прикрепени към inode. Преименуването в една файлова система променя записа в директорията и нищо друго, което е бързо, атомарно и причината контекстът да преживее преместването. Никаква политика не се пита, никаква стойност по подразбиране не се прилага и никакво предупреждение не се отпечатва.

Копирането се държи различно. Копието създава нов inode в целевата директория и политиката задава контекст от типа на тази директория, затова копиран сертификат обикновено получава правилен етикет, докато преместеният остава грешен. Тази единствена разлика обяснява по-голямата част от объркването в този клас заявки.

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

Прочетете текущия етикет срещу очаквания

Три команди само за четене отговарят на въпроса, без да променят нищо. Първата показва какво има файлът сега, втората съобщава какво очаква политиката за точно този път, а третата изброява всеки файл в директорията, чийто етикет се различава.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

След това свържете разликата с действителен отказ. Несъответствието е доказателство за грешен етикет, а не доказателство, че услугата се е провалила заради него, и поправка, приложена без съответен отказ в журнала, е догадка с допълнителни стъпки.

Възстановете съответствието, вместо да измисляте изключение

За стандартно място политиката вече съпоставя пътя, затова restorecon го прилага и работата е свършена. Дръжте обхвата в директорията, която поправяте; преетикетирането на цялата файлова система е бавно, разрушително и заравя първоначалната грешка под много голяма промяна.

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon прилага съпоставяне; не може да измисли такова. Ако нито едно правило не описва пътя, няма от какво да се възстанови, затова постоянното съпоставяне трябва да съществува преди преетикетирането. Запишете коя конфигурация притежава това съпоставяне, защото по-късно преместване, актуализация на пакет или преетикетиране иначе пресъздава дефекта и следващият човек започва от нула.

Защо chcon не е решението

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

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

Когато етикетът е правилен, а достъпът все още се проваля

Започнете с родителските директории. Разрешението за преминаване се проверява на всеки компонент от пътя, затова правилно етикетиран сертификат в директория, в която услугата не може да влезе, остава нечетим. И SELinux, и обикновеното разрешение трябва да позволяват всяка стъпка, а поправянето на едното не поправя другото.

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

Помнете, че правилата dontaudit могат да потискат съобщенията за отказ, затова празният одитен журнал е слабо доказателство, а не доказателство. Ако политиката изглежда правилна, а достъпът все още се проваля, разследвайте, преди да генерирате широк модул за разрешаване, и не изключвайте SELinux, за да изчезне симптомът. И двата кратки пътя дават система, която изглежда, че работи, и позиция за сигурност, която никой не може да опише. Кратко разследване е по-добро от всяко от двете.