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