Fayl ruxsatlari xavfsizligi: eng kam imtiyoz va audit

chmod 777 deyarli har doim Permission denied xatosini yo'qotadi va deyarli hech qachon haqiqiy muammoni hal qilmaydi: aynan kimga qaysi amal kerakligini aniqlash o'rniga u hujum yuzasini tizimdagi har bir lokal hisobgacha kengaytiradi. Production’da to'g'ri savol hech qachon "qaysi rejim buni ishlatib yuboradi?" emas — "qaysi jarayonga qaysi obyekt ustida qaysi amalni bajarish kerak?" bo'lishi kerak.

Bu maqola Fayl ruxsatlari, Egalik, Maxsus ruxsatlar, umask va Root va sudo maqolalaridagi mexanizmlarni haqiqiy xavfsizlik siyosatiga aylantiradi. Quyida fayl va kataloglarga eng kam imtiyoz tamoyilini qo'llashni; maxfiylik, yaxlitlik va mavjudlik xavflarini rejim, egalik va katalog tuzilmasi bilan bog'lashni; hamma yoza oladigan fayllar, yozish mumkin bo'lgan bajariladigan fayllar, maxsus bitlar va egasiz obyektlarni find bilan audit qilishni o'rganamiz. Shuningdek, ls -l bilan birga getfacl, namei, findmnt va MAC loglarini o'qishni; kod, konfiguratsiya, maxfiy ma’lumotlar va runtime ma’lumotlari uchun siyosatni ajratishni; production’dagi ruxsat xatosini haqiqiy hisob bilan tekshirilgan va ishlaydigan rollback’ga ega eng kichik o'zgarish bilan tuzatishni ko'rib chiqamiz.

Ruxsat — shunchaki son emas, xavfsizlik siyosati

Linux’ning oddiy user/group/other modeli ixtiyoriy kirish nazorati (discretionary access control, DAC) deyiladi. "Ixtiyoriy" — obyektning oddiy ruxsatlarini uning egasi boshqarishini bildiradi. Kernel jarayon identifikatorini fayl egasi va guruhi bilan solishtiradi, so'ng tegishli r, w yoki x bitini tekshiradi.

Xavfsizlik nuqtai nazaridan har bir bit uchta savoldan biriga javob beradi:

• Maxfiylik (confidentiality): mazmunni kim o'qiy oladi?
• Yaxlitlik (integrity): mazmunni yoki katalog yozuvini kim o'zgartira oladi?
• Mavjudlik (availability): muhim narsani kim o'chira, almashtira yoki unga kirishni to'sa oladi?

.env faylni hamma o'qiy olishi — maxfiylik muammosi. Xizmatning bajariladigan fayliga xizmatning o'z hisobi yoza olishi — yaxlitlik muammosi: buzilgan jarayon keyingi safar o'zi ishga tushiradigan kodni ustidan yozib qo'yishi mumkin. Ortiqcha w+x ga ega katalog boshqa foydalanuvchiga muhim yozuvni o'chirishga imkon beradi — bu esa mavjudlik muammosi.

Eng kam imtiyozni aniq yozib qo'yish

Eng kam imtiyoz "eng kichik ko'rinadigan sonni tanlash" degani emas. Siyosat to'rt qismdan iborat:

1. sub’ekt: amalni bajarayotgan jarayon yoki administrator.
2. obyekt: fayl, katalog, symlink yoki boshqa resurs.
3. amal: o'qish, yozish, bajarish, nom yaratish yoki yo'l bo'ylab o'tish.
4. vaqt va kontekst: bu ehtiyoj doimiymi yoki faqat deploy paytidami?

Masalan, veb-xizmatga o'z konfiguratsiyasini o'qish har doim kerak bo'lishi mumkin, lekin o'zining deploy kodiga yozish hech qachon kerak bo'lmaydi. Deploy hisobi yangi reliz yaratishi kerak bo'lishi mumkin, lekin runtime maxfiy ma’lumotini hech qachon o'qimasligi kerak. Agar ikkala rol uchun bitta umumiy app guruhi ishlatilsa, rejim raqamlari tartibli ko'rinishi mumkin, ostidagi siyosat esa zaif bo'lib qoladi.

Kod, konfiguratsiya va runtime ma’lumotlarini ajrating

Hamma fayllarni bitta egalik va rejim bilan boshqarish qulay, lekin bu buzilgan xizmat uchun keraksiz yozish yo'llarini ochadi. Odatiy server ilovasi kamida quyidagi toifalarga bo'linadi:

Bu jadval aniq rejimlarning universal ro'yxati emas. Masalan, 0640 root:catalog maxfiy ma’lumot uchun faqat catalog guruhiga begona odam yoki xizmat a’zo bo'lmasagina o'rinli tanlov. Agar bir-biriga aloqasi yo'q bir nechta jarayon bitta guruhni ulashsa, xuddi shu rejim ortiqcha o'qish huquqini beradi.

Keng tarqalgan, xavfsizroq tuzilma:

/srv/catalog/current/       root:catalog      read/execute for the service
/etc/catalog/app.env        root:catalog      read-only for the service
/var/lib/catalog/           catalog:catalog   read/write for the service
/var/log/catalog/           catalog:adm       write, with controlled audit

Aniq egasi, guruhi va rejimi ilovaning o'z ishlash modeli va distributiv siyosatiga bog'liq. Muhim chegara shundaki, xizmat yozishi kerak bo'lgan kataloglar uning kodi va konfiguratsiyasidan ajratilgan.

Xavfsiz laboratoriya

Quyidagi laboratoriya faqat ~/lab/permission-security test daraxti ichida ataylab zaif rejimlar yaratadi. U tizim kataloglariga tegmaydi va sudo talab qilmaydi. Kod bloklaridagi qatorlarda $ yoki # prompt belgisi yo'q.

mkdir -p ~/lab/permission-security/{bin,config,data,uploads}
printf '%s\n' '#!/usr/bin/env bash' 'echo "report ready"' \
    > ~/lab/permission-security/bin/run-report.sh
printf '%s\n' 'DB_PASSWORD=test-only-secret' \
    > ~/lab/permission-security/config/app.env
printf '%s\n' 'record-001' \
    > ~/lab/permission-security/data/records.txt

chmod 0777 ~/lab/permission-security/bin/run-report.sh
chmod 0666 ~/lab/permission-security/config/app.env
chmod 0777 ~/lab/permission-security/uploads
chmod 0644 ~/lab/permission-security/data/records.txt

find ~/lab/permission-security -xdev -printf '%y %m %u:%g %p\n'

Namunaviy, tegishli parcha:

f 777 ali:ali /home/ali/lab/permission-security/bin/run-report.sh
f 666 ali:ali /home/ali/lab/permission-security/config/app.env
d 777 ali:ali /home/ali/lab/permission-security/uploads
f 644 ali:ali /home/ali/lab/permission-security/data/records.txt

Uy katalogi yo'li va hisob nomlari tizimga qarab farq qiladi. Agar run-report.sh, app.env va uploads aynan shu rejimlarni ko'rsatsa, laboratoriya audit uchun tayyor.

find bilan xavfga yo'naltirilgan audit

find -perm faqat rejim bitlarini tekshiradi. U ACL mask’ini, faqat o'qish rejimidagi mount’ni, AppArmor, SELinux yoki NFS serverining o'z qarorini hisobga olmaydi. Shuning uchun natija o'z-o'zidan xavfsizlik xulosasi emas, ko'rib chiqilishi kerak bo'lgan nomzodlar ro'yxati.

Boshqalar yoza oladigan fayllar

other uchun yozish biti o'rnatilgan oddiy fayllarni topish:

find ~/lab/permission-security -xdev -type f -perm -0002 \
    -printf '%m %u:%g %p\n'

Kutiladigan natija:

777 ali:ali /home/ali/lab/permission-security/bin/run-report.sh
666 ali:ali /home/ali/lab/permission-security/config/app.env

-perm -0002 other-write biti bo'lishini talab qiladi va qolgan barcha bitlarni e’tiborga olmaydi. 0666 rejimidagi maxfiy fayl nafaqat hammaga o'qishga, balki uning mazmunini ustidan yozishga ham imkon beradi.

Yozish mumkin bo'lgan bajariladigan fayllar

Agar bajariladigan faylga guruh yoki boshqalar yoza olsa, uni ishga tushiradigan yuqoriroq huquqli jarayon almashtirilgan kodni bajarib qo'yish xavfi bor:

find ~/lab/permission-security -xdev -type f \
    -perm /0111 -perm /0022 \
    -printf '%m %u:%g %p\n'

/0111 egasi, guruh yoki boshqalarning bajarish bitlaridan birortasini qidiradi; /0022 esa guruh yoki boshqalarning yozish bitlaridan birortasini qidiradi. Ikki shart yonma-yon turgani uchun fayl ikkalasiga ham mos kelishi kerak. / shakli GNU find kengaytmasi va Ubuntu Server hamda RHEL oilasi bilan keladigan GNU Findutils’da mavjud.

Sticky bit’siz hamma yoza oladigan kataloglar

find ~/lab/permission-security -xdev -type d \
    -perm -0002 ! -perm -1000 \
    -printf '%m %u:%g %p\n'

Laboratoriyadagi uploads shu yerda chiqadi. Sticky bit’siz hamma yoza oladigan katalog kirish huquqi bor istalgan foydalanuvchiga boshqa foydalanuvchining katalog yozuvlarini o'chirish yoki almashtirish imkonini beradi. /tmp kabi umumiy katalog odatda sticky bit bilan himoyalangan — uning mexanizmi Maxsus ruxsatlar maqolasida ko'rib chiqilgan.

setuid, setgid va egasiz obyektlar

Production daraxtini faqat o'qish orqali ko'rib chiqish uchun:

app_root='/srv/<app>'

sudo find "$app_root" -xdev -type f -perm /6000 \
    -printf 'special %m %u:%g %p\n'

sudo find "$app_root" -xdev \( -nouser -o -nogroup \) \
    -printf 'unmapped %m %u:%g %p\n'

sudo cheklangan kataloglarni audit qilish uchun kerak; bu topilgan har bir narsa avtomatik ravishda xavfli degani emas. /6000 setuid yoki setgid dan birortasiga mos keladi va bu yerda paket bilan kelgan qonuniy imtiyozli bajariladigan fayl ham chiqishi mumkin. -nouser/-nogroup UID/GID i hozir NSS bazasida nomga mos kelmaydigan obyektlarni topadi.

Katta daraxtda auditni chegaralash

Production auditini / dan boshlash odatda shovqinli va sekin bo'ladi. Maqsadni aniq chegaralang:

app_root='/srv/<app>'

realpath -- "$app_root"
stat -c '%F %A %U:%G %n' -- "$app_root"
findmnt -R -T "$app_root"
sudo find -P "$app_root" -xdev -maxdepth 3 \
    -printf '%y %m %u:%g %p\n'

-P symlink’lar ortidan bormaslikni aniq belgilaydi va find da boshlang'ich yo'ldan oldin yoziladi. -xdev boshqa mount’ga o'tib ketishning oldini oladi, -maxdepth 3 esa birinchi o'tishni chegaralaydi — chuqurroq ko'rish kerak bo'lsa, chuqurlikni ongli ravishda oshiring. Ruxsat xatolarini yashirish uchun 2>/dev/null qo'shmang, aks holda audit qamrovi aslidagidan to'liqroq ko'rinadi.

ls -l ko'rsatmaydigan qatlamlar

Klassik rejim to'g'ri ko'rinsa ham, boshqa qatlamlar haqiqiy qarorga baribir ta’sir qilishi mumkin.

ACL va amaldagi mask

ls -l da ruxsatlar satridan keyingi + kengaytirilgan ACL borligini bildirishi mumkin:

ls -ld -- <path>
getfacl -p -- <path>

Namunaviy natija:

user::rw-
user:backup:r--
group::r--
mask::r--
other::---

Nomlangan foydalanuvchi backup da r-- bor. ACL’dagi mask::r-- nomlangan foydalanuvchi, nomlangan guruh va ega guruh yozuvlari uchun amaldagi ruxsatni cheklaydi. Masalan, yozuv user:backup:rw- bo'lsa-yu, mask r-- bo'lsa, backup amalda faqat o'qish huquqini oladi. getfacl buni ko'pincha #effective:r-- izohi bilan ko'rsatadi.

Katalogdagi default ACL uning ichida yaratiladigan yangi obyektlarning boshlang'ich ACL’iga ta’sir qiladi. Bitta chmod o'zgarishi ACL mask’ini tasodifan o'zgartirib yuborishi mumkin, shuning uchun + ni ko'rganingizda o'zgarishdan oldin va keyin getfacl natijasini saqlab qo'ying.

Debian/Ubuntu’da getfacl acl paketidan keladi. RHEL oilasida ham ACL vositalari odatda acl paketi bilan keladi.

ACL o'rnatish: egalikni o'zgartirmasdan bitta qo'shimcha foydalanuvchiga ruxsat berish

ACL’ni o'qish faqat allaqachon topilgan + ni tushuntiradi. Haqiqiy hayotda ko'proq uchraydigan vazifa — obyekt egasi, guruhi o'zgartirmasdan yoki hammaga kengroq rejim bermasdan bitta qo'shimcha hisobga ruxsat berish. Klassik owner/group/other modeli aynan shu holatni o'zi ifodalay olmaydi: "fayl deploy ga tegishli, lekin backup ham uni o'qishi kerak, boshqa hech kim esa yo'q".

sudo setfacl -m u:backup:r-- /srv/catalog/current/release.tar.gz
getfacl -p /srv/catalog/current/release.tar.gz

# file: srv/catalog/current/release.tar.gz
user::rw-
user:backup:r--
group::r--
mask::r--
other::---

-m ACL’ni o'zgartiradi — bitta yozuvni qo'shadi yoki yangilaydi; u:backup:r-- nomlangan backup foydalanuvchisiga, uning guruh a’zoligidan qat’i nazar, faqat o'qish huquqini beradi. Faylning egasi va asosiy guruhi o'zgarmaydi — ls -l o'sha egasi va guruhni ko'rsataveradi, oxirida esa kengaytirilgan ACL ni bildiruvchi + paydo bo'ladi.

Default ACL: yangi fayllar ruxsatni avtomatik meros qilib olishi

-m bilan o'rnatilgan ACL faqat o'zi qo'llangan obyektga ta’sir qiladi. Bir nechta hisob ulashadigan katalogda esa yangi fayllar xuddi shu ruxsatni avtomatik olishi kerak — default ACL aynan shuni qiladi:

sudo setfacl -d -m u:backup:r-- /srv/catalog/shared
getfacl -p /srv/catalog/shared

# file: srv/catalog/shared
user::rwx
group::rwx
other::r-x
default:user::rwx
default:user:backup:r--
default:group::rwx
default:mask::rwx
default:other::r-x

-d yozuvni default sifatida belgilaydi va u faqat shundan keyin shu katalog ichida yaratiladigan obyektlarga qo'llanadi. U u yerda allaqachon mavjud fayllarni ortga qarab o'zgartirmaydi va mos default bo'lmagan yozuv ham qo'shilmasa, backup ga katalogning o'ziga hech qanday ruxsat bermaydi. Merosni tasdiqlash:

sudo -u catalog -- touch /srv/catalog/shared/new-release.tar.gz
getfacl -p /srv/catalog/shared/new-release.tar.gz

Yangi faylning ACL’ida katalogning default’idan meros olingan user:backup:r-- allaqachon bo'lishi kerak. Bu "har bir deploy’dan keyin chmod qilmasdan, shu jamoadagi har kim umumiy katalogga tashlangan yangi fayllarni o'qiy oladi" degan holat ortidagi standart mexanizm.

Mount parametrlari

findmnt -T <path> -o TARGET,SOURCE,FSTYPE,OPTIONS

ro yozishni, noexec bajariladigan faylni to'g'ridan-to'g'ri ishga tushirishni bloklashi mumkin, nosuid esa setuid/setgid ta’sirini cheklaydi. Mount siyosatini fayl rejimini kengaytirib "tuzatishga" urinish butunlay noto'g'ri qatlamni o'zgartirishdir.

AppArmor va SELinux

Ubuntu Server odatda AppArmor’ni, RHEL oilasi esa SELinux’ni DAC ustidan majburiy kirish nazorati (mandatory access control, MAC) sifatida qo'llaydi. DAC amalga ruxsat bersa ham, MAC siyosati baribir uni rad etishi mumkin.

Ubuntu’da faqat o'qiydigan diagnostika:

aa-status
journalctl -k --grep='apparmor="DENIED"' --since today

RHEL oilasida:

getenforce
ls -Zd -- <path>
sudo ausearch -m AVC -ts recent

ausearch audit logini o'qish uchun yuqori huquq talab qilishi mumkin. Rad etish aynan qaysi profil/kontekst, jarayon, obyekt va amalga tegishli ekanini tekshiring.

Noto'g'ri SELinux kontekstini tuzatish

DAC bo'yicha to'g'ri bo'lgan faylni ham, agar uning turi (type) xizmat siyosati kutgan turga mos kelmasa, SELinux rad etishi mumkin. Bu RHEL oilasidagi tizimlarda "ruxsatlarni to'g'ri qo'ydim, lekin baribir Permission denied" holatining juda keng tarqalgan sababi, ayniqsa faylni kutilmagan joydan ko'chirgandan keyin (ko'chirish maqsad katalogning emas, manba katalogning kontekstini saqlab qoladi).

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

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

Agar fayl /var/www/html ga, masalan, uy katalogidan nusxalangan bo'lsa, u ko'pincha httpd_sys_content_t o'rniga user_home_t yorlig'ini oladi va DAC rejimi to'g'ri ko'rinsa ham, Apache siyosati uni o'qishga ruxsat bermaydi. Buni tuzatishning ikki usuli bor:

sudo restorecon -v /var/www/html/index.html

restorecon fayl kontekstini tizim siyosati bazasi shu yo'l uchun bo'lishi kerak deb belgilagan qiymatga qaytaradi. Bu xavfsiz, standart yechim, chunki u yangi qoida o'ylab topmaydi, faqat mavjudini qayta qo'llaydi.

Agar yo'l yangi bo'lsa va unga mos qoida hali yo'q bo'lsa, avval siyosatning o'ziga moslik qo'shib, keyin uni qo'llash kerak:

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/webapp(/.*)?'
sudo restorecon -Rv /srv/webapp

semanage fcontext -a yo'l andozasini turga bog'laydigan va kelajakdagi qayta yorliqlashdan (relabel) keyin ham saqlanadigan doimiy qoida qo'shadi; restorecon -Rv esa uni shu yo'l ostida allaqachon mavjud fayllarga rekursiv qo'llaydi. Bir martalik chcon yorliqni darhol o'zgartiradi, lekin to'liq qayta yorliqlash yoki restorecon ishga tushgandan keyin saqlanmaydi, shuning uchun u faqat tezkor, vaqtinchalik sinov uchun foydali:

sudo chcon -t httpd_sys_content_t /srv/webapp/index.html

AppArmor profili rejimini o'zgartirish

AppArmor profillari ikki rejimdan birida ishlaydi va aa-status yuklangan har bir profil qaysi rejimda ekanini ko'rsatadi:

sudo aa-status

apparmor module is loaded.
50 profiles are loaded.
45 profiles are in enforce mode.
   /usr/sbin/nginx
   ...
5 profiles are in complain mode.
   /usr/sbin/tcpdump
   ...

• enforce: profil aniq ruxsat berilmagan har qanday narsani faol bloklaydi va rad etishni logga yozadi.
• complain: profil faqat nima rad etilgan bo'lardi ekanini logga yozadi, lekin aslida bloklamaydi. Bu profilni ishlab chiqish yoki sozlash paytida ishlatiladi, shunda yangi deploy nimaga muhtojligini uni qulflashdan oldin ko'rasiz.

Tizim bo'ylab himoyani o'chirmasdan, AppArmor sabab bo'lgan deb gumon qilingan nosozlikni tashxislash paytida profilni complain rejimiga o'tkazish:

sudo aa-complain /usr/sbin/nginx
sudo systemctl restart nginx
journalctl -k --grep='apparmor="ALLOWED"' --since '5 minutes ago'

Rad etilishi kerak bo'lgan har bir amal endi DENIED o'rniga ALLOWED (complain rejimida) sifatida logga yoziladi. Bu xizmatni to'xtatmasdan yetishmayotgan qoidalar ro'yxatini tuzish imkonini beradi. Profil qonuniy xatti-harakatni qamrab oladigan qilib tuzatilgach, uni qaytaring:

sudo aa-enforce /usr/sbin/nginx
sudo aa-status | grep -A2 nginx

Capabilities va allaqachon ochiq fayllar

CAP_DAC_OVERRIDE yoki CAP_DAC_READ_SEARCH kabi capability’ga ega jarayon ba’zi oddiy ruxsat tekshiruvlarini chetlab o'ta oladi:

getcap -- <executable_path>

Agar fayl allaqachon ochilgan bo'lsa, keyinroq uning rejimini toraytirish mavjud fayl deskriptorini avtomatik bekor qilmaydi. Hodisa paytida chmod bilan cheklanmang — obyektni hali ham ochiq ushlab turgan jarayonlarni lsof <path> bilan aniqlang. Jarayonni to'xtatish yoki qayta ishga tushirish xizmatga ta’sir qiladi, shuning uchun tasdiqlangan hodisa va rollback tartibiga amal qiling.

Zaif laboratoriyani xavfsiz holatga keltirish

Avval joriy rejim, egalik va ACL’ning zaxira nusxasini oling:

getfacl -Rp ~/lab/permission-security > ~/lab/permission-security.acl.before
chmod 0600 ~/lab/permission-security.acl.before

Agar getfacl bo'lmasa, acl paketini o'rnatish administrator huquqini talab qiladi. Bu izolyatsiyalangan laboratoriya katalogini qayta yaratishning o'zi rollback vazifasini bajarishi mumkin; production’da esa vosita yo'qligi hech qachon zaxira nusxasiz biror narsani o'zgartirishga sabab bo'la olmaydi.

Laboratoriya siyosati:

• skriptni egasi o'qiydi, unga yozadi va uni bajaradi; joriy guruh uni o'qiy va bajara oladi;
• test maxfiy ma’lumotini faqat egasi o'qiydi va unga yozadi;
• ma’lumotlar fayliga egasi yozadi, guruh esa uni o'qiydi;
• yuklangan fayllar katalogiga faqat egasi kira oladi va yoza oladi.

Aynan shu test daraxti uchun:

chmod 0750 ~/lab/permission-security/bin
chmod 0750 ~/lab/permission-security/bin/run-report.sh
chmod 0700 ~/lab/permission-security/config
chmod 0600 ~/lab/permission-security/config/app.env
chmod 0750 ~/lab/permission-security/data
chmod 0640 ~/lab/permission-security/data/records.txt
chmod 0700 ~/lab/permission-security/uploads

Bu aniq rejimlarni haqiqiy ilovaga ko'chirmang. Ular universal javob emas, balki yuqorida yozilgan siyosatning natijasi.

Auditlarni qayta ishga tushiring:

find ~/lab/permission-security -xdev -type f -perm -0002 \
    -printf 'world-writable %m %p\n'
find ~/lab/permission-security -xdev -type f \
    -perm /0111 -perm /0022 \
    -printf 'writable-executable %m %p\n'
find ~/lab/permission-security -xdev -type d \
    -perm -0002 ! -perm -1000 \
    -printf 'unsafe-shared-dir %m %p\n'

Uchalasi ham hech narsa qaytarmasligi kerak. So'ng funksional tekshiruv:

~/lab/permission-security/bin/run-report.sh
test -r ~/lab/permission-security/config/app.env
echo $?

Agar report ready va 0 chiqsa, kerakli funksionallik saqlangan. Natija kutilmagan bo'lsa:

setfacl --restore=~/lab/permission-security.acl.before
find ~/lab/permission-security -xdev -printf '%y %m %u:%g %p\n'

Amaliy vaziyat: xizmat o'z kodi va maxfiy ma’lumotiga yoza oladi

catalog.service catalog hisobi ostida ishlaydi. Audit quyidagilarni topdi:

-rwxrwxrwx catalog:catalog /srv/catalog/current/bin/catalog
-rw-r--r-- catalog:catalog /etc/catalog/app.env
drwxrwxrwx catalog:catalog /var/lib/catalog/uploads

Xizmat ishlayapti, lekin xavfsizlik chegarasi noto'g'ri:

• bajariladigan faylni ham xizmat, ham istalgan boshqa hisob almashtira oladi;
• maxfiy ma’lumotni har bir lokal hisob o'qiy oladi, xizmatning o'z egaligi esa unga rejimni ham o'zgartirishga imkon beradi;
• yuklangan fayllar katalogiga hamma yoza oladi va unda sticky bit yo'q.

Ko'zlangan siyosat: kod va maxfiy ma’lumotni root boshqaradi; catalog ularni faqat o'qiy/bajara oladi; xizmat faqat yuklangan fayllar katalogiga yozadi.

1. Haqiqiy identifikator va yo'llarni tekshiring

service_name='catalog.service'
app_binary='/srv/catalog/current/bin/catalog'
secret_file='/etc/catalog/app.env'
upload_dir='/var/lib/catalog/uploads'

systemctl show -p User -p Group "$service_name"
id catalog
namei -l "$app_binary"
namei -l "$secret_file"
findmnt -T "$app_binary" -o TARGET,FSTYPE,OPTIONS
stat -c '%A %a %U(%u):%G(%g) %n' \
    "$app_binary" "$secret_file" "$upload_dir"
getfacl -p "$app_binary" "$secret_file" "$upload_dir"

O'zgaruvchilarni haqiqiy xizmat nomi va absolyut yo'llar bilan almashtiring. systemctl show hozir ishlab turgan jarayonni har doim ham isbotlamaydi; kerak bo'lsa, ps -o pid,user,group,comm -C <process_name> bilan tekshiring.

2. Kerakli amallarni xizmat hisobi ostida sinab ko'ring

Maxfiy ma’lumotni uning mazmunini terminalga chiqarmasdan o'qish mumkinligini tekshiring:

sudo -u catalog -- sh -c 'exec 3<"$1"' sh "$secret_file"
echo $?
sudo -u catalog -- test -w "$app_binary"
echo $?
sudo -u catalog -- test -w "$upload_dir"
echo $?

Hozirgi zaif holatda uchala holat ham 0 bo'lishi mumkin. Birinchi 0 kerakli o'qish huquqini, ikkinchisi bajariladigan faylga yozish mumkinligini, uchinchisi esa yuklangan fayllar katalogiga yozish mumkinligini tasdiqlaydi. Ko'zlangan siyosatga ko'ra faqat ikkinchi natija noldan farqli bo'lishi kerak: xizmat maxfiy ma’lumotni o'qiy olishi va yuklangan fayllar katalogiga yoza olishi, lekin hech qachon o'zining bajariladigan fayliga yoza olmasligi kerak.

3. Snapshot va metama’lumotlar zaxira nusxasi

Production’da VM/saqlash tizimi snapshot’ini oling yoki konfiguratsiyani boshqarish holatini qayd eting. Bunga qo'shimcha:

backup_file=$(sudo mktemp /root/catalog-permissions.before.XXXXXX)
sudo getfacl -p "$app_binary" "$secret_file" "$upload_dir" \
    | sudo tee "$backup_file" >/dev/null
sudo chmod 0600 "$backup_file"
printf '%s\n' "$backup_file"

Chiqarilgan yo'lni o'zgarishlar qaydiga yozing. Bu zaxira nusxa faqat nomlangan uchta obyektni qamraydi — agar ota katalog yoki ichki fayllar ham o'zgartirilayotgan bo'lsa, avval ularni zaxira doirasiga qo'shing.

4. Eng kichik o'zgarish

sudo chown root:catalog -- "$app_binary" "$secret_file"
sudo chmod 0750 -- "$app_binary"
sudo chmod 0640 -- "$secret_file"
sudo chown catalog:catalog -- "$upload_dir"
sudo chmod 0750 -- "$upload_dir"

Boshqa egasi/guruhni berish uchun sudo kerak. Bu buyruqlar faqat oldindan tekshirilgan uchta obyektga tegadi va rekursiv emas. root:catalog 0750 bajariladigan faylni xizmat guruhi uchun o'qish/bajarishga ochadi, yozish esa root da qoladi. root:catalog 0640 xizmat guruhiga maxfiy ma’lumotni o'qish huquqini beradi va uni boshqa barcha hisoblar uchun yopadi.

5. Natija va xizmatni tekshiring

stat -c '%A %a %U:%G %n' \
    "$app_binary" "$secret_file" "$upload_dir"
getfacl -p "$app_binary" "$secret_file" "$upload_dir"

sudo -u catalog -- sh -c 'exec 3<"$1"' sh "$secret_file"
echo $?
sudo -u catalog -- test ! -w "$app_binary"
echo $?
sudo -u catalog -- test -w "$upload_dir"
echo $?

Endi uchala holat ham 0 bo'lishi kerak: maxfiy ma’lumot ochiladi, binar faylga yozib bo'lmaydi, yuklangan fayllar katalogiga esa yozish mumkin. Xizmat konfiguratsiya yoki bajariladigan faylni o'zgarishdan oldin allaqachon ochib qo'ygan bo'lishi mumkin — loglarni va health check’ni kuzating. Ruxsat o'zgarishining o'zi xizmatni qayta ishga tushirishni avtomatik talab qilmaydi.

6. Rollback

Agar monitoring yoki funksional test kutilmagan natija ko'rsatsa:

sudo setfacl --restore="$backup_file"
stat -c '%A %a %U:%G %n' \
    "$app_binary" "$secret_file" "$upload_dir"

setfacl --restore zaxira nusxadan egasi, guruhi, rejimi va ACL’ni tiklaydi. Agar tashkilotingizning snapshot yoki deploy rollback’i ishonchliroq bo'lsa, o'sha yo'ldan foydalaning.

Production auditini foydali qilish

Bir martalik find xavfsizlik nazorati emas. Ishlaydigan audit quyidagi xususiyatlarga ega:

• kutilgan holat yozib qo'yilgan: qaysi yo'l qaysi egasi/guruh va ruxsat berilgan amallarga ega bo'lishi kerakligi oldindan ma’lum;
• qamrov chegaralangan: mount’lar, symlink’lar va ataylab qilingan istisnolar aniq belgilangan;
• natija solishtiriladi: yangi ishga tushirishning oldin tasdiqlangan holatdan farqlari ajratib olinadi;
• egasi bor: topilmani kim ko'rib chiqishi va qachon tuzatilishi aniq;
• rollback sinab ko'rilgan: ACL, egalik va maxsus atributlarni tiklash haqiqatan tekshirilgan;
• deploy bilan bog'langan: ruxsatlardagi og'ish keyingi relizda jimgina qaytib kelmaydi.

Rejimlarni qayta-qayta qo'lda tuzatish o'rniga manbani — paket, image, deploy manifesti yoki konfiguratsiyani boshqarish tizimida tuzating. Aks holda serverda to'g'ridan-to'g'ri qilingan tezkor tuzatish keyingi deploy’da yo'qolib ketadi.

Keng tarqalgan xatolar

Ishlashini tiklash uchun 777 ni tezkor yechim sifatida ishlatish

Xato vaqtincha yo'qoladi, lekin har bir lokal hisob uchun yozish va bajarish yo'li ochiladi. Buning o'rniga jarayon identifikatori, ota katalog, ACL’lar va MAC sababini toping va faqat yetishmayotgan amalga ruxsat bering.

Faqat faylning o'z rejimiga qarash

Ota katalogdagi ortiqcha w+x boshqa foydalanuvchiga faylning nomini butunlay almashtirishga imkon berishi mumkin. Butun yo'lni namei -l bilan, ACL’larni getfacl bilan, mount’ni esa findmnt bilan tekshiring.

Xizmatga butun loyiha daraxtini berish

Runtime’da yozish uchun reliz kodi va maxfiy ma’lumotlarni xizmatning o'z egaligiga berish shart emas. Yozish mumkin bo'lgan ma’lumotlarni /var/lib/<service> kabi alohida katalogga ajrating.

Har bir audit natijasini zaiflik deb belgilash

/tmp ning sticky bit’li, hamma yoza oladigan katalog bo'lishi yoki paketning setuid bajariladigan fayli butunlay qonuniy bo'lishi mumkin. Topilmani uning vazifasi, egasi, paket manbasi va har qanday qo'shimcha himoya qatlami bo'yicha baholang.

find -perm ni haqiqiy kirish testi deb hisoblash

-perm faqat inode rejim bitlarini solishtiradi. ACL’lar, MAC, faqat o'qish rejimidagi mount va NFS moslashtirish har biri boshqacha haqiqiy qaror berishi mumkin. Yakuniy dalilni muayyan xizmat hisobi ostida bajarilgan haqiqiy, yon ta’sirsiz amaldan oling.

DAC xatosini yashirish uchun MAC’ni o'chirish

AppArmor yoki SELinux rad etishi siyosat va joylashuv haqiqatan mos kelmasligini bildirishi mumkin. Himoyani global o'chirish o'rniga logda sub’ekt, obyekt, amal va kutilgan yorliq/profilni tekshiring.

Faqat mavjud fayllarni tuzatish

Bugungi chmod ertangi yangi fayllarning rejimini hal qilmaydi. Yaratish siyosati umask, default ACL’lar, setgid katalog va deploy vositasiga bog'liq. Yaratish manbasini ham tuzating, aks holda og'ish qaytib keladi.

Zaxira nusxa rejimni saqlaydi deb o'ylash

Ba’zi nusxalash yoki arxivlash usullari ACL, egalik, kengaytirilgan atributlar yoki file capabilities ni saqlamaydi. Tiklashni sinab ko'rayotganda mazmun bilan birga metama’lumotlarni ham tekshiring.

Mashqlar

1. Laboratoriyaning zaif holatida hamma yoza oladigan fayllar, yozish mumkin bo'lgan bajariladigan fayllar va sticky bit’siz hamma yoza oladigan kataloglar auditlarini bajaring. Har bir natijani maxfiylik, yaxlitlik yoki mavjudlik xavfi bilan bog'lang.
2. app.env uchun ls -l, stat va getfacl natijalarini solishtiring. Qaysi vosita mos ravishda rejim, raqamli UID/GID va ACL haqidagi savollarga javob berishini qayd eting.
3. Avval o'zingizning laboratoriya siyosatingizni yozing, so'ng undan kerakli rejimlarni hisoblab chiqaring. Ortida siyosat bo'lmagan tayyor sonlarni ko'chirmang.
4. Rejimlari 0620, 0602 va 0622 bo'lgan uchta test faylda find -perm /0022 va find -perm -0022 ni solishtiring. Har bir natija bilan "birorta bit" va "barcha bitlar" farqini isbotlang.
5. Taxminiy xizmat uchun kod, maxfiy ma’lumot, runtime ma’lumotlari va yuklangan fayllar kataloglarini rejalashtiring. Har biri uchun egasi, guruhi, kerakli amallar, audit buyrug'i va rollback manbasini belgilang.

Mashqni bajardim deyish uchun: har bir javob sub’ekt, obyekt va kerakli amalni aniq ko'rsatishi kerak; "xato yo'qoldi" degan gapni xavfsizlik isboti sifatida ishlatmang.

Laboratoriyani tugatganingizda avval maqsadni tekshiring:

find ~/lab/permission-security -xdev -maxdepth 3 \
    -printf '%y %m %u:%g %p\n'

Agar natijada faqat laboratoriya daraxti ko'rinsa:

rm -rI -- ~/lab/permission-security
rm -i -- ~/lab/permission-security.acl.before

Bu modul nimani beradi

Bu modul davomida ruxsatlar statik sondan boshqariladigan siyosatga aylandi: Foydalanuvchi va guruh hisoblari qolgan hamma narsa tayanadigan UID/GID identifikatorlarini o'rnatdi; Fayl ruxsatlari kernel bitta sinfni qanday tanlashi va bitta bitni qanday tekshirishini ko'rsatdi; Egalik "egasi" va "guruh" aslida qayerdan kelishini tushuntirdi; Maxsus ruxsatlar bajariladigan faylning identifikatori yoki umumiy katalogdagi meros qanday o'zgarishi mumkinligini ko'rsatdi; umask yangi yaratilgan obyektning boshlang'ich ruxsati qanday hal qilinishini yoritdi; Root va sudo esa yuqori huquq butunlay berilmasdan, qanday chegaralanishini ko'rsatdi. Bu maqola hammasini faqat rejim raqamiga emas, sub’ekt, obyekt va amalga asoslangan, audit qilinadigan xavfsizlik siyosatiga birlashtirdi.

Keyingi modul ishlab turgan dasturlar aynan shu identifikatorlardan qanday foydalanishiga o'tadi: jarayon nima, uning resurslari qanday kuzatiladi va u ishlayotgan paytda uni qanday kuzatish hamda boshqarish mumkin.

Manbalar

• Linux man-pages: path_resolution(7): https://man7.org/linux/man-pages/man7/path_resolution.7.html
• Linux man-pages: inode(7): https://man7.org/linux/man-pages/man7/inode.7.html
• Linux man-pages: acl(5): https://man7.org/linux/man-pages/man5/acl.5.html
• Linux man-pages: capabilities(7): https://man7.org/linux/man-pages/man7/capabilities.7.html
• GNU Findutils qo'llanmasi: mode bits: https://www.gnu.org/software/findutils/manual/html_node/find_html/Mode-Bits.html
• GNU Findutils qo'llanmasi: symbolic links: https://www.gnu.org/software/findutils/manual/html_node/find_html/Symbolic-Links.html
• Linux kernel hujjatlari: /proc/sys/fs: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/fs.html
• Ubuntu Server hujjatlari: AppArmor: https://ubuntu.com/server/docs/how-to/security/apparmor/
• Red Hat Enterprise Linux 9: getting started with SELinux: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/getting-started-with-selinux_using-selinux
• Red Hat Enterprise Linux 9: managing SELinux file contexts (semanage fcontext, restorecon, chcon): https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_selinux/mngin-selinux-file-context_using-selinux
• Ubuntu qo'llanma sahifasi: aa-status(8), aa-complain(8), aa-enforce(8): https://manpages.ubuntu.com/manpages/noble/man8/aa-status.8.html
• Linux man-pages: setfacl(1), getfacl(1): https://man7.org/linux/man-pages/man1/setfacl.1.html
• POSIX.1-2024: file access permissions: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html