Зашто премештање 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 да би симптом нестао. Оба кратка пута дају систем који изгледа да ради и безбедносни став који нико не може да опише. Кратко истраживање је боље од било ког од њих.