SELinux va AppArmor

Linux xavfsizligi asoslari maqolasida Mandatory Access Control (MAC) jarayonni uning DAC ruxsatlari nimaga imkon berishidan qat’i nazar cheklaydigan siyosat qatlami sifatida tanishtirilgan edi. Fayl ruxsatlari xavfsizligi maqolasida esa "fayl ruxsatlari to'g'ri bo'lsa ham permission denied" muammosini aniqlash kontekstida asosiy diagnostika buyruqlari, noto'g'ri belgilangan SELinux kontekstini qanday tuzatish va AppArmor profili rejimini qanday tekshirish ko'rsatilgan edi. Bu maqola har bir tizimni o'z xususiyatlari bilan chuqurroq ko'rib chiqadi: siyosat aslida qanday tuzilgani, majburlash rejimlarini qanday xavfsiz o'zgartirish, yangi AppArmor profilini noldan qanday qurish va xom audit yozuvlarini qo'lda talqin qilish o'rniga, rad etish (denial) uchun tuzatishni SELinux’ning o'zi qanday taklif qilishiga imkon berish.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• SELinux’ning enforcing/permissive/disabled rejimlarini tushuntirish va ular orasida xavfsiz almashish;
• SELinux kontekstini o'qish va siyosatning o'zini tahrirlamasdan uni sozlash uchun boolean’ni almashtirish;
• audit2allow yordamida rad etishni ko'rib chiqish mumkin bo'lgan siyosat moduliga aylantirish;
• aa-genprof/aa-logprof bilan ilova uchun yangi AppArmor profilini qurish;
• ma’lum bir rad etish uchun to'g'ri tuzatish kontekstni o'zgartirishmi, boolean’mi yoki haqiqiy siyosat istisnosimi, hal qilish.

SELinux: rejimlar va yuklanish vaqtidagi almashtirgich

SELinux uchta rejimdan birida ishlaydi va u getenforce bilan tekshiriladi:

getenforce

Enforcing

setenforce 0/setenforce 1 Enforcing va Permissive o'rtasida darhol almashtiradi, lekin o'zgarish qayta yuklanishdan keyin saqlanib qolmaydi. U siyosat uchun emas, vaqtinchalik troubleshooting uchun mo'ljallangan:

sudo setenforce 0
getenforce

Permissive

Doimiy o'zgarish /etc/selinux/config ga yoziladi:

sudo nano /etc/selinux/config

SELINUX=enforcing
SELINUXTYPE=targeted

SELINUXTYPE=targeted deyarli har bir RHEL oilasi o'rnatmasida standart siyosat. U tarmoqqa qaragan daemon’larning aniq, tanlab olingan ro'yxatini (httpd, sshd, named va boshqalar) cheklaydi, boshqa jarayonlarning ko'pchiligini esa cheklanmagan holda qoldiradi. Ancha kam uchraydigan mls turi butun tizimga to'liq ko'p darajali xavfsizlik (multi-level security) label’larini qo'llaydi va rasmiy maxfiylik darajalari talabi bor muhitlar uchun mo'ljallangan.

Kontekstni o'qish va DAC/MAC farqi

SELinux konteksti to'rt qismdan iborat — user, role, type va sensitivity. Lekin kundalik administratsiyada deyarli har doim type muhim bo'ladi:

ls -Z /var/www/html/index.html

unconfined_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

httpd_sys_content_t — bu type. Siyosat httpd_t jarayon turi (Apache’ning o'zi shu tur sifatida ishlaydi) qaysi turlarni o'qishi, ularga yozishi yoki bajarishi mumkinligini belgilaydi. Shuning uchun faylni home katalogdan web root’ga ko'chirish rwx bitlari to'g'ri bo'lsa ham Permission denied ga olib kelishi mumkin. Fayl manba joyidan user_home_t ni meros qilib oladi, targeted siyosatidagi hech bir qoida esa httpd_t ga user_home_t ni o'qish huquqini bermaydi. Fayl ruxsatlari xavfsizligi maqolasi aynan shu holatni restorecon va semanage fcontext bilan aniqlash va tuzatishni bosqichma-bosqich ko'rsatadi. O'sha tuzatish bu yerda ham o'zgarishsiz qo'llaniladi.

Boolean’lar: siyosatni tahrirlamasdan sozlash

Ko'plab keng tarqalgan siyosat murosalari maxsus qoida yozishni talab qilish o'rniga boolean'lar sifatida taqdim etiladi. Bular siyosat muallifi oldindan ko'zda tutgan, nomlangan yoqish/o'chirish almashtirgichlari:

getsebool -a | grep httpd

httpd_can_network_connect --> off
httpd_can_sendmail --> off
httpd_enable_homedirs --> off

httpd_can_network_connect off to'g'ri label’langan, ruxsatlari to'g'ri bo'lgan PHP ilovasi ham nega masofaviy API’ga yoki boshqa hostdagi ma’lumotlar bazasiga ulana olmasligi mumkinligini tushuntiradi. SELinux’ning targeted siyosati standart holatda httpd_t dan chiquvchi tarmoq ulanishlarini rad etadi. Sababi: web kontentning ko'p qismi statik, ixtiyoriy chiquvchi ulanishlar qilayotgan buzib kirilgan web ilova esa o'z-o'zidan bloklashga arziydigan signal.

sudo setsebool -P httpd_can_network_connect on

-P o'zgarishni qayta yuklanishlardan keyin ham saqlanadigan qiladi. Usiz setsebool faqat ishlab turgan tizimga ta’sir qiladi — bu setenforce va /etc/selinux/config ni tahrirlash o'rtasidagi vaqtinchalik va doimiy farqning xuddi o'zi. Mavjud boolean’ni almashtirish har doim xuddi shu xatti-harakat uchun maxsus siyosat istisnosini yozishdan afzal. Chunki bu siyosat ta’minotchilari allaqachon ko'rib chiqqan va doirasini belgilagan o'zgarish, yangi, audit qilinmagan qoida emas.

audit2allow: rad etishni ko'rib chiqiladigan siyosatga aylantirish

Hech bir mavjud boolean qonuniy ehtiyojni qamrab olmasa va restorecon/semanage fcontext qo'llanilmasa (chunki muammo faqat label’da emas, kirishning o'zi haqiqatan siyosat ruxsat bergan doiradan tashqarida bo'lsa), audit2allow yozib olingan rad etishni o'qiydi va unga ruxsat beradigan aniq siyosat modulini hosil qiladi:

sudo ausearch -m AVC -ts recent | audit2allow -M mycustompolicy

******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i mycustompolicy.pp

cat mycustompolicy.te

module mycustompolicy 1.0;

require {
    type httpd_t;
    type var_lib_t;
    class file { read open };
}

#============= httpd_t ==============
allow httpd_t var_lib_t:file { read open };

Hosil qilingan bu qoidani o'rnatishdan oldin har safar ko'rib chiqish kerak. audit2allow bu kirishga haqiqatan ruxsat berilishi kerakmi yoki yo'qmi, baho bermasdan, aynan rad etilgan kirishga ruxsat beradi. Bitta AVC rad etishi qonuniy, tor talabni aks ettirishi ham, ilova umuman qilmasligi kerak bo'lgan ishni qilishga urinayotganini aks ettirishi ham mumkin. Har bir audit2allow taklifini o'qimasdan o'rnatish SELinux’ni qoidabuzarliklarni log'ga yozib, keyin ularga jimgina ruxsat beradigan tizimga aylantiradi, bu esa uning maqsadini yo'qqa chiqaradi.

sudo semodule -i mycustompolicy.pp

AppArmor: profil rejimlari va yangi profil qurish

Ubuntu’ning standart MAC tizimi bo'lgan AppArmor SELinux’ning label’ga asoslangan yondashuvi o'rniga yo'lga (path) asoslangan yondashuvdan foydalanadi: profil nomi ko'rsatilgan bajariladigan fayl foydalanishi mumkin bo'lgan aniq fayllar, capabilities va tarmoq kirishini sanab o'tadi.

sudo aa-status

apparmor module is loaded.
50 profiles are loaded.
45 profiles are in enforce mode.
5 profiles are in complain mode.

• enforce — qoidabuzarliklar bloklanadi va log'ga yoziladi. Bu SELinux’ning Enforcing rejimining AppArmor’dagi ekvivalenti;
• complain — qoidabuzarliklar faqat log'ga yoziladi. Bu Permissive ga teng va yangi profil hali ishlab chiqilayotgan paytdagi standart rejim.

Profilni noldan qurish: aa-genprof

Mavjud profili bo'lmagan ilova uchun aa-genprof ilova aslida nima qilishini kuzatib, profil yaratish jarayonini interaktiv tarzda bosqichma-bosqich olib boradi:

sudo aa-genprof /usr/local/bin/mydaemon

Writing updated profile for /usr/local/bin/mydaemon.
Please start the application to be profiled in
another window and exercise its functionality now.

Once completed, select the "Scan" option below in order
to scan the system logs for AppArmor events.

[(S)can system log for AppArmor events] / (F)inish

Profil endi joyida va complain rejimida bo'lgani holda, ilova o'zining odatiy, qonuniy ish oqimlari orqali sinovdan o'tkaziladi — har bir route, har bir rejalashtirilgan vazifa, ishga tushish va to'xtashning har bir yo'li. Bu paytda aa-genprof profil hali qamrab olmagan har qanday narsani log'dan kuzatib boradi va unga ruxsat berish kerakmi, deb interaktiv so'raydi:

Profile:  /usr/local/bin/mydaemon
Path:     /etc/mydaemon/config.yaml
New Mode: r

[1 - #include <abstractions/base>]
 2 - /etc/mydaemon/config.yaml r,
(A)llow / (D)eny / (I)gnore / (G)lob / (N)ew / (C)lean exit / (Q)uit

Bu SELinux’ning audit2allow iga qaraganda ancha ko'proq qo'l mehnatini talab qiladi va bu ongli murosa. U ilova nima so'ragan bo'lsa, shuni avtomatik kodlash o'rniga, har bir kirish shabloni uchun profil yozish bosqichidayoq inson qaror qabul qilishini majburlaydi.

Mavjud profilni takomillashtirish: aa-logprof

Birinchi qoralama profil paydo bo'lgach, aa-logprof xuddi shu "log'ni skanerlash va so'rash" siklini davom etayotgan faoliyatga nisbatan bajaradi. Profil bir muddat complain rejimida bo'lganidan keyin, uni enforce ga o'tkazishdan oldin kuzatilgan qonuniy xatti-harakatni profilga kiritish uchun davriy ishga tushiriladigan vosita shu:

sudo aa-logprof

Profil rejimini almashtirish

sudo aa-complain /usr/local/bin/mydaemon    # observe only, log but don't block
sudo aa-enforce /usr/local/bin/mydaemon     # block anything the profile doesn't allow

Profil real, vakillik qiladigan foydalanishdagi xatti-harakati yangi log yozuvlarini hosil qilmay qo'ymaguncha complain rejimida qolishi kerak. enforce ga juda erta o'tish ishlab chiqish paytida hali hech kim sinab ko'rmagan qonuniy funksionallikni bloklab qo'yadi.

Keng tarqalgan xatolar

• Rad etishni yo'qotish uchun SELinux’ni Disabled ga o'rnatish. Yuqorida ko'rib chiqilganidek, bu rad etilishi mumkin bo'lgan narsalarning kelajakdagi barcha log yozuvlarini ham o'chiradi, keyinchalik uni qayta yoqish esa butun fayl tizimini to'liq qayta label’lashni boshlaydi. To'g'ri vaqtinchalik diagnostika holati — Permissive.
• Har bir audit2allow taklifini o'qimasdan o'rnatish. Hosil qilingan siyosat ruxsat berilishi kerakmi yoki yo'qmi, baho bermasdan, aynan rad etilgan narsaga ruxsat beradi. semodule -i dan oldin .te faylini ko'rib chiqish ixtiyoriy emas.
• Yangi AppArmor profilini to'g'ridan-to'g'ri enforce ga o'tkazish. Ilovaning real foydalanish shablonlarini qamrab olgan complain rejimidagi kuzatuv davrisiz enforce rejimi profil ishlab chiqish paytida hech kim sinab ko'rmagan qonuniy yo'llarni bloklaydi.
• Boolean va maxsus siyosat modulini bir-birining o'rnini bosadigan deb hisoblash. Boolean — oldindan ko'rib chiqilgan, doirasi belgilangan almashtirgich. audit2allow hosil qilgan maxsus modul esa yangi, audit qilinmagan qoida. Har doim avval mavjud boolean’ni tekshiring.

Mashqlar

1. RHEL oilasidagi lab VM’da Permissive rejimiga o'ting, bloklanishini biladigan amalni bajarishga urinib rad etishni qayta yarating, keyin ausearch va audit2allow yordamida u qanday siyosat hosil qilishini ko'ring — uni o'rnatmasdan.
2. O'zingiz ishlatadigan servisga tegishli boolean’ni toping (getsebool -a | grep <service>) va faqat uning nomidan kelib chiqib, u qanday murosani boshqarishini tushuntiring.
3. Ubuntu lab VM’da o'zingizning kichik skriptingizga nisbatan aa-genprof ni ishga tushiring, uning odatiy xatti-harakatini sinab ko'ring va profilni yakunlang. Uning natijaviy rejimini aa-status bilan tekshiring.
4. Xavfsizlik jamoasi sekinroq bo'lishiga qaramay, nega SELinux’ning audit2allow i o'rniga AppArmor’ning qo'lda, har bir qarorni alohida qabul qiladigan profillash jarayonini afzal ko'rishi mumkinligini tushuntiring.

Xulosa

SELinux ham, AppArmor ham oddiy fayl ruxsatlari ustiga majburiy siyosat qatlamini qo'shadi, lekin ular turli yondashuvlardan foydalanadi. SELinux obyektlar va jarayonlarni type’lar bilan label’laydi va siyosatni shu type’larga nisbatan baholaydi: getenforce/setenforce vaqtinchalik rejim o'zgarishlarini boshqaradi, boolean’lar oldindan ko'rib chiqilgan siyosat almashtirgichlarini beradi, audit2allow esa yangi istisnolarni hosil qiladi (lekin hech qachon avtomatik tasdiqlamaydi). AppArmor profilni to'g'ridan-to'g'ri bajariladigan faylning yo'liga biriktiradi va u enforce ga o'tkazilishidan oldin complain rejimida aa-genprof/aa-logprof bilan bosqichma-bosqich quriladi. Keyingi maqola, Firewall va UFW, xuddi shu default deny falsafasini jarayon diskda nimaga tega olishidan hostga tarmoq orqali umuman nima yetib kela olishiga ko'chiradi.

Manbalar

• Red Hat: Using SELinux
• man7.org: selinux(8)
• man7.org: audit2allow(1)
• Ubuntu Server hujjatlari: AppArmor
• Debian Wiki: AppArmor