VPN sertifikatini ko'chirish nima uchun uning SELinux yorlig'ini buzadi

Sertifikatlar to'g'ri katalogda o'qiladigan rejim va root egaligi bilan turishi mumkin, va xizmat baribir faylni ocha olmasligini xabar qilishi mumkin. SELinux tizimida bu birikma ruxsatlarga emas, balki bitta aniq mexanizmga ishora qiladi. Yorliq fayl bilan birga ko'chdi, chunki qayta nomlash yangi obyekt yaratmaydi. inode eski yo'lda ega bo'lgan xavfsizlik kontekstini saqlab qoldi, yangi yo'l siyosati esa hech qachon o'z kontekstini belgilash imkoniyatini olmadi.

Qayta nomlash yorliqqa aslida nima qiladi

Fayl o'z SELinux kontekstini inode'ga bog'langan atribut ma'lumoti sifatida olib yuradi. Bitta fayl tizimi ichida qayta nomlash katalog yozuvini o'zgartiradi va boshqa hech narsani emas, bu tez va atomar, va kontekstning ko'chirishdan keyin saqlanib qolishining sababi ham shu. Hech qanday siyosat so'ralmaydi, hech qanday standart qo'llanilmaydi va hech qanday ogohlantirish chop etilmaydi.

Nusxalash boshqacha harakat qiladi. Nusxa maqsad katalogda yangi inode yaratadi, siyosat kontekstni o'sha katalog turiga qarab belgilaydi, shuning uchun nusxalangan sertifikat odatda to'g'ri yorliq oladi, ko'chirilgani esa noto'g'ri qoladi. Aynan shu bitta farq bu turdagi biletlardagi chalkashlikning ko'p qismini tushuntiradi.

Fayl tizimlari orasidagi ko'chirish nusxalash semantikasiga qaytadi, shuning uchun bir xil buyruq ikki mashinada /etc o'z hajmida joylashganmi yoki yo'qmi ga qarab boshqacha harakat qilishi mumkin. Asbob ishonchsiz degan xulosaga kelishdan oldin buni tekshiring. mount jadvaliga bir qarash qanday turdagi ko'chirish qilganingizni aytadi.

Joriy yorliqni kutilgan yorliq bilan o'qing

Faqat o'qish uchun uchta buyruq hech narsani o'zgartirmasdan savolga javob beradi. Birinchisi faylda hozir nima borligini ko'rsatadi, ikkinchisi siyosat aynan shu yo'l uchun nimani kutishini xabar qiladi, uchinchisi esa katalog ostidagi yorlig'i boshqacha bo'lgan har bir faylni sanab chiqadi.

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

Ishonish kerak bo'lgan narsa quruq ishga tushirishdir, chunki u konteksti siyosatdan chetga chiqqan har bir faylni nomlaydi va tizimga baribir tegmaydi. Agar sertifikat o'sha ro'yxatda ko'rinsa, yo'l nimani anglatishi va fayl nima da'vo qilishi orasidagi nomuvofiqlikni topdingiz. Agar ko'rinmasa, yorliq allaqachon siyosat xohlagan narsa, va sizning vaqtingiz boshqa joyga tegishli.

So'ngra farqni haqiqiy rad etish bilan bog'lang. Nomuvofiqlik noto'g'ri yorliqning dalili, xizmat shu sababli muvaffaqiyatsiz bo'lganining isboti emas, va jurnalda mos keladigan rad etishsiz qo'llanilgan tuzatish qo'shimcha qadamlar bilan qilingan taxmin.

Istisno o'ylab topish o'rniga xaritalashni tiklang

Standart joy uchun siyosat yo'lni allaqachon xaritalaydi, shuning uchun restorecon uni qo'llaydi va ish tugaydi. Qamrovni siz tuzatayotgan katalogda saqlang; butun fayl tizimini qayta yorliqlash sekin, xalaqit beradi va asl xatoni juda katta o'zgarish ostida ko'madi.

Maxsus katalog uchun tartib muhim, va uni teskari aylantirish hech narsani o'zgartirmasdan muvaffaqiyat haqida xabar beradigan buyruq hosil qiladi. Xaritalash siyosatga tegishli, qayta yorliqlash oxiriga tegishli, quruq ishga tushirish esa ikkalasidan oldin. O'sha oxirgi qismni o'tkazib yuborish hech qachon noto'g'ri bo'lmagan yo'lning baribir qayta yorliqlanish usulidir.

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

restorecon xaritalashni qo'llaydi; u uni o'ylab topa olmaydi. Agar hech qanday qoida yo'lni tasvirlamasa, tiklash uchun hech narsa yo'q, shuning uchun doimiy xaritalash qayta yorliqlashdan oldin mavjud bo'lishi kerak. Qaysi konfiguratsiya o'sha xaritalashga ega ekanini yozib qo'ying, chunki aks holda keyingi ko'chirish, paket yangilanishi yoki qayta yorliqlash nuqsonni yana yaratadi va keyingi odam noldan boshlaydi.

Nima uchun chcon yechim emas

chcon kontekstni to'g'ridan-to'g'ri faylga yozadi. U darhol kuchga kiradi va mavjud eng kam bardoshli variant, chunki fayl tizimini qayta yorliqlash siyosatni qaytadan qo'llaydi va so'ramasdan qo'lda kiritilgan o'zgarishlarni tashlab yuboradi. Fayl tuzatilgandek ko'rinadi va tuzatishning hech kim yozmagan amal qilish muddati bor. Buning o'rniga sizga yo'lni tasvirlaydigan qoida kerak, shunda u yerga keladigan har bir fayl avtomatik ravishda bir xil munosabatni oladi.

Undan yomoni, bu noto'g'ri saboq beradi: asosiy xaritalash hali ham yo'q, shuning uchun nuqson haftalar o'tib aniq qo'zg'atuvchisiz va o'sha aylanib o'tish haqida xotirasiz qaytadi. chcon dan faqat farazni tasdiqlash uchun vaqtinchalik tajriba sifatida foydalaning, so'ng uni keyingi qayta yorliqlashga bardosh beradigan xaritalash bilan almashtiring va almashtirma haqiqatan joyida ekanini tekshiring.

Yorliq to'g'ri bo'lganda va kirish baribir muvaffaqiyatsiz bo'lganda

Ota kataloglardan boshlang. O'tish ruxsati yo'lning har bir komponentida tekshiriladi, shuning uchun xizmat kira olmaydigan katalog ichidagi to'g'ri yorliqlangan sertifikat ham o'qilmaydigan bo'lib qoladi. SELinux ham, oddiy ruxsat ham har bir qadamga ruxsat berishi kerak, va birini tuzatish ikkinchisini tuzatmaydi.

So'ngra jarayon identifikatori va xizmatning o'z sandbox'ini tekshiring. Cheklovchi sandbox'ga ega birlik siyosat bajonidil ruxsat beradigan faylga kirishni rad etishi mumkin, va jurnal satridan ikki sabab bir xil ko'rinadi. Aslida qaysi jarayon so'rayotganini tasdiqlang, siz so'rayapti deb o'ylagan jarayonni emas.

dontaudit qoidalari rad etish xabarlarini bosishi mumkinligini unutmang, shuning uchun bo'sh audit jurnali isbot emas, zaif dalil. Agar siyosat to'g'ri ko'rinsa va kirish baribir muvaffaqiyatsiz bo'lsa, keng ruxsat modulini yaratishdan oldin tekshirib chiqing, va simptom yo'qolishi uchun SELinux'ni o'chirmang. Ikkala qisqa yo'l ham ishlayotgandek ko'rinadigan tizim va hech kim tasvirlab bera olmaydigan xavfsizlik pozitsiyasini beradi. Qisqa tekshiruv ikkalasidan ham yaxshi.