Root va sudo: administrator huquqini nazorat qilish

Serverni boshqarishda ba’zan yuqori huquq kerak bo'ladi, lekin butun sessiyani root sifatida o'tkazish har bir xato yozuv, har bir noto'g'ri o'zgaruvchi va har bir buzilgan dasturning ta’sirini kattalashtiradi. sudo administratorlikni "hammasi yoki hech narsa" holatidan muayyan foydalanuvchi, maqsadli hisob, host va buyruq bilan chegaralanadigan siyosatga aylantiradi.

umask maqolasi jarayon uchun ruxsat bitlari qanday hal qilinishi haqidagi manzarani yakunladi; bu maqola esa o'sha jarayon eng avvalo qaysi identifikator ostida ishlashi haqida. Quyida root, UID 0, /root va / ni bir-biridan ajratamiz; muayyan vazifa uchun su, sudo, sudo -u, sudo -i va sudo -s orasidan tanlashni; sudo -l, -v, -k va -- ni amalda ishlatishni; shell yo'naltirishi nega sudo ishga tushishidan oldin bajarilishini tushunishni; sudoers qoidasining foydalanuvchi, host, RunAs va buyruq qismlarini o'qishni; drop-in faylni visudo bilan sintaktik tekshirishni o'rganamiz. Shuningdek, ruxsat berilgan bitta buyruq ortida ham keng imkoniyat yashirinishi mumkinligini baholab, sudo logi yordamida aslida nima bajarilganini ko'ramiz.

Root nima va nima emas

root — odatda UID 0 ga ega administrator hisobiga beriladigan nom. Kernel uchun nom emas, raqamli UID va jarayonning capabilities lari muhim. Linux an’anaviy superuser imkoniyatlarini alohida capabilities ga bo'lgan, lekin UID 0 sifatida ishlayotgan jarayon odatda baribir fayl ruxsatlari tekshiruvlarining ko'pchiligini chetlab o'ta oladigan keng to'plamga ega bo'ladi.

Bir-biriga o'xshab ko'rinadigan uch atamani adashtirmang:

• root: hisob, odatda UID 0.
• /root: shu hisobning uy katalogi.
• /: fayl tizimi daraxtining ildizi.

Joriy jarayonning identifikatorini prompt’dagi # belgisiga qarab emas, buyruq bilan tekshiring:

id
id -u
whoami
printf 'HOME=%s PWD=%s\n' "$HOME" "$PWD"

Oddiy foydalanuvchi uchun namunaviy natija:

uid=1000(ali) gid=1000(ali) groups=1000(ali),27(sudo)
1000
ali
HOME=/home/ali PWD=/home/ali

Agar id -u 0 qaytarsa, joriy jarayon root sifatida ishlayapti. groups=...sudo Ubuntu’ning keng huquqli administrator guruhiga a’zolikni bildirishi mumkin, lekin aslida aynan qaysi buyruqlarga ruxsat berilganini sudo -l hal qiladi.

UID 0 hisoblarini audit qilish

Lokal /etc/passwd dagi UID 0 yozuvlarini faqat o'qish orqali tekshiring:

awk -F: '$3 == 0 {printf "user=%s uid=%s home=%s shell=%s\n", $1, $3, $6, $7}' /etc/passwd

Odatiy natija:

user=root uid=0 home=/root shell=/bin/bash

Kutilmagan ikkinchi UID 0 hisobi root bilan bir xil klassik superuser identifikatoriga ega. Nega u mavjudligini tushunmasdan uni o'chirmang — u tiklash mexanizmi, maxsus qurilma (appliance) yoki katalog xizmati siyosati bilan bog'liq bo'lishi mumkin. /etc/passwd faqat lokal yozuvlarni ko'rsatadi; markazlashgan NSS manbalari bo'lsa, ularni ham identifikatsiya jamoangiz bilan birga audit qiling.

su va sudo bir xil ishni bajarmaydi

su maqsadli foydalanuvchi identifikatori ostida shell yoki buyruqni ishga tushiradi. Oddiy foydalanuvchi su ni ishga tushirganda autentifikatsiya odatda maqsadli hisobning o'z paroliga va PAM siyosatiga tayanadi:

su [options] [-] [user [argument...]]

To'liq login muhitini olish uchun:

su --login <username>

--login muhitning katta qismini tozalaydi, HOME, SHELL, USER va LOGNAME ni o'rnatadi, PATH ni maqsadli hisobga moslaydi, uning uy katalogiga o'tadi va login shell’ni ishga tushiradi. Oddiy su <username> esa joriy katalog va muhitning bir qismini saqlab qoladi va ikki hisobning muhitini aralashtirib yuborishi mumkin.

sudo esa siyosat plaginidan so'raydi: "bu chaqiruvchi aynan shu buyruqni shu maqsad sifatida bajara oladimi?" Sukut bo'yicha maqsadli foydalanuvchi root, lekin -u boshqa hisobni tanlaydi:

sudo [options] [command [argument...]]
sudo -u user [options] [command [argument...]]

Masalan, faylni root sifatida emas, xizmatning o'z hisobi ostida tekshirish:

sudo -u <service_account> -- id
sudo -u <service_account> -- test -r <file_path>
echo $?

Bu yerda sudo imtiyozni oshirish uchun umuman ishlatilmayapti: u sinov uchun administrator sessiyasidan kamroq huquqli maqsadli hisobga tushish uchun ishlatilmoqda. -- undan keyingi hamma narsa sudo opsiyasi emas, buyruq ekanini belgilaydi.

sudo su - odatda keraksiz qo'shimcha qatlam: sudo root sifatida su ni ochadi, su esa uning ustiga yana bitta root shell ochadi. Qaysi siyosat kimga qo'llanganini ko'rish va audit qilish qiyinlashadi. Iloji bo'lsa, maqsadni to'g'ridan-to'g'ri sudo -i yoki sudo -u bilan ifodalang.

PAM: sudo va su ortidagi autentifikatsiya siyosati

su ham, sudo ham "parol to'g'rimi va bu hisob hozir umuman autentifikatsiyadan o'tishi mumkinmi" degan haqiqiy qarorni /etc/shadow ni o'zlari tekshirish o'rniga Pluggable Authentication Modules (PAM) ga topshiradi. Shuning uchun bitta sudo binar fayli serverdagi PAM sozlamasiga qarab lokal parolni, LDAP katalogini, apparat tokenini tekshirishi yoki juda ko'p xatodan keyin loginni to'g'ridan-to'g'ri rad etishi mumkin — siyosat uni chaqiradigan dasturdan tashqarida yashaydi.

/etc/pam.d/: har bir xizmat uchun bitta fayl, ketma-ket qoidalar

Foydalanuvchilarni autentifikatsiya qiladigan har bir xizmatning /etc/pam.d/ ostida o'z fayli bor — /etc/pam.d/sudo, /etc/pam.d/su, /etc/pam.d/sshd va hokazo:

cat /etc/pam.d/sudo

#%PAM-1.0
session    required   pam_limits.so
session    required   pam_env.so readenv=1 user_readenv=0
@include common-auth
@include common-account
@include common-session-noninteractive

@include common-auth umumiy faylni ulaydi, shunda bir xil autentifikatsiya siyosatini har bir xizmatda takrorlash shart bo'lmaydi. Ichidagi har bir qator quyidagi ko'rinishga ega:

type    control    module    [arguments]

• type — bosqich: auth (identifikatorni tasdiqlash), account (hisobga ruxsat berilganmi — muddati tugaganmi, qulflanganmi, vaqt bo'yicha cheklanganmi), password (hisob ma’lumotini o'zgartirish) yoki session (sessiya atrofidagi sozlash va yakunlash, masalan yuqoridagi pam_limits.so).
• module — haqiqiy tekshiruvni bajaradigan .so fayl, masalan pam_unix.so (an’anaviy /etc/shadow tekshiruvi) yoki pam_faillock.so.
• control — shu qatorning natijasi butun stack natijasiga qanday ta’sir qilishini hal qiladi:

required va requisite farqi bitta aniq sabab bilan muhim: required muvaffaqiyatsizlikdan keyin ham qolgan tekshiruvlarni ataylab davom ettiradi, shunda tizimni sinab ko'rayotgan hujumchi vaqt yoki xatti-harakatga qarab aynan qaysi tekshiruv birinchi bo'lib muvaffaqiyatsiz bo'lganini bila olmaydi. requisite esa buning evaziga darhol to'xtashni tanlaydi. Bu davom etish ma’nosiz yoki xavfli bo'lganda o'rinli (masalan, hisob qulflangani tasdiqlangandan keyin).

pam_faillock: takroriy muvaffaqiyatsiz loginlarni bloklash

pam_faillock — "login so'rovida parolni qayta-qayta taxmin qilishni qanday to'xtatish mumkin" degan savolga OT darajasidagi standart javob. U ma’lum vaqt oralig'ida hisob uchun ketma-ket muvaffaqiyatsiz autentifikatsiyalarni sanaydi va chegaraga yetganda hisobni qulflaydi. Bu tarmoq qatlami (masalan, SSH loglarini kuzatayotgan fail2ban) nima qilayotganidan mustaqil ishlaydi.

RHEL oilasidagi tizimlar pam_faillock ni authselect orqali sukut bo'yicha yoqadi. Ubuntu’da u libpam-modules paketi bilan keladi, lekin common-auth ga oldindan ulanmagan, shuning uchun uni aniq qo'shish kerak — yoki sudo pam-auth-update bilan (agar Faillock profili taklif qilinsa), yoki PAM stack’ini to'g'ridan-to'g'ri tahrirlash orqali. Har ikki holatda ham hosil bo'lgan stack common-auth da (RHEL oilasida system-auth da) pam_faillock ni pam_unix atrofiga quyidagi ko'rinishda joylashtiradi:

auth    required                                     pam_faillock.so preauth
auth    [success=1 default=ignore]                   pam_unix.so nullok
auth    [default=die]                                pam_faillock.so authfail
auth    required                                      pam_faillock.so authsucc

• preauth: parol tekshiruvidan oldin ishlaydi va hisob allaqachon qulflangan bo'lsa, darhol rad etadi.
• pam_unix.so parolni tekshirgandan keyin authfail yangi muvaffaqiyatsizlikni qayd etadi (bunga faqat pam_unix.so muvaffaqiyatli bo'lmagan holda yetib boriladi), authsucc esa muvaffaqiyatli loginda muvaffaqiyatsizliklar hisoblagichini tozalaydi.

Eng muhim sozlamalar /etc/security/faillock.conf da (yoki to'g'ridan-to'g'ri modul argumentlari sifatida) bo'ladi:

grep -E '^(deny|fail_interval|unlock_time)' /etc/security/faillock.conf 2>/dev/null

• deny: ketma-ket nechta muvaffaqiyatsizlik hisobni qulflaydi.
• fail_interval: bu muvaffaqiyatsizliklar hisobga olinishi uchun ular tushishi kerak bo'lgan siljuvchi vaqt oralig'i.
• unlock_time: qulf avtomatik ochilgunga qadar qancha davom etadi (0 — administrator aralashmaguncha qulflangan qoladi).

Qulflanishni avval faqat o'qish orqali tekshirish va keyin tozalash:

sudo faillock --user <username>

<username>:
When                Type  Source                                           Valid
2026-07-29 09:14:02 RHOST 203.0.113.10                                     V
2026-07-29 09:14:05 RHOST 203.0.113.10                                     V

Har bir qator — qayd etilgan bitta muvaffaqiyatsizlik, mavjud bo'lsa uning manba manzili bilan. Sabab tushunilgach — masalan, bu faol hujum emas, haqiqatan unutilgan parol bo'lsa — qulfni aniq tozalang:

sudo faillock --user <username> --reset

sudo bilan kundalik xavfsiz ish tartibi

Avval siyosatni tekshiring

sudo --version
sudo -l

sudo --version amalga oshirish (implementation) va versiyani ko'rsatadi; sudo -l esa joriy foydalanuvchiga ruxsat berilgan buyruqlarni ko'rsatadi. sudo -l parol so'rashi mumkin; odatda chaqiruvchi o'z parolini kiritadi, lekin PAM va sudo siyosati bu xatti-harakatni o'zgartirishi mumkin.

Qisqartirilgan namunaviy natija:

User ali may run the following commands on web01:
    (root) /usr/bin/systemctl reload catalog.service
    (www-data) /usr/bin/php /srv/catalog/bin/health.php

Birinchi qoida ali ga catalog.service ni faqat root sifatida reload qilishga ruxsat beradi; ikkinchisi muayyan PHP health check’ini www-data sifatida ishga tushirishga ruxsat beradi. (ALL) ALL kabi qoida amalda juda keng huquq beradi.

Muayyan buyruq siyosatga mos keladimi-yo'qligini uni ishga tushirmasdan tekshirish:

sudo -l /usr/bin/systemctl reload catalog.service
echo $?

0 siyosat mos kelishini bildiradi; noldan farqli holat yo ruxsat yo'qligini, yo autentifikatsiya xatosini bildiradi. Bu buyruq xizmatni reload qilmaydi.

Vaqt tamg'asini boshqarish

Muvaffaqiyatli autentifikatsiyadan keyin sudo hisob ma’lumotlari bo'yicha vaqt tamg'asini (timestamp) ma’lum muddat saqlab turishi mumkin:

sudo -v

-v buyruq bajarmasdan vaqt tamg'asini yangilaydi va parol so'rashi mumkin. Administrator ishi tugagach:

sudo -k

-k joriy vaqt tamg'asini bekor qiladi; keyingi sudo odatda qayta autentifikatsiya talab qiladi. Vaqt tamg'asi yozuvini butunlay o'chirish uchun -K dan foydalanish mumkin, lekin oddiy sessiyani yopishda -k yetarli.

So'rovda kutib qolmasligi kerak bo'lgan avtomatlashtirish uchun -n bilan interaktiv bo'lmagan rejim mavjud:

sudo -n -l
echo $?

Yaroqli hisob ma’lumoti yoki NOPASSWD siyosati bo'lmasa, -n so'rov chiqarish o'rniga darhol xato bilan tugaydi. Parolni skriptga yozish yoki uni echo password | sudo -S ... bilan yashirish xavfsiz avtomatlashtirish usuli emas.

Root shell o'rniga bitta buyruqni afzal ko'ring

sudo -- systemctl status <service_name>.service

Bu yerda sudo yuqori huquqni faqat systemctl jarayoniga beradi. sudo -i esa login root shell’ni ochadi va undan keyingi hamma narsa yuqori huquq bilan bajariladi:

sudo -i
id
pwd
exit

sudo -s ham maqsadli shell’ni ochadi, lekin login muhitini to'liq taqlid qilmaydi; shell va muhit joriy sozlamalarga ko'proq bog'liq bo'ladi. Tiklash yoki bir-biriga bog'liq bir nechta amal haqiqatan root shell talab qilishi mumkin, lekin avval snapshot/konsol, aniq tekshiruv ro'yxati va qachon chiqish kerakligi mezonini tayyorlang.

sudo ishga tushishidan oldin shell nima qiladi

Shell yo'naltirishi, globbing va o'zgaruvchilarni kengaytirish sudo ishga tushishidan oldin bajariladi. Shu sababli:

sudo printf '%s\n' 'value' > /etc/<app>/app.conf

odatda xato bilan tugaydi: printf root bo'lishi mumkin, lekin > yo'naltirishi uchun /etc/... ni oddiy, imtiyozsiz joriy shell ochadi.

Agar maqsad tayyor faylni xavfsiz rejim bilan o'rnatish bo'lsa, shu ish uchun yaratilgan vosita aniqroq:

sudo install -o root -g <service_group> -m 0640 \
    <verified_source_file> /etc/<app>/app.conf

Matn oqimini yozish uchun sudo tee dan foydalanish mumkin:

printf '%s\n' 'value' | sudo tee /etc/<app>/app.conf >/dev/null

tee mavjud fayl mazmunini o'chirib, yangisi bilan almashtiradi; maxfiy ma’lumot terminal tarixiga yoki jarayon argumentlariga tushib qolishi mumkin. Production’da buni qilishdan oldin joriy faylni, zaxira nusxani, sintaksis tekshiruvini va atomar deploy usulini bilib oling.

sudo sh -c '...' yo'naltirish muammosini chetlab o'tadi, chunki shell’ning o'zi root bo'ladi, lekin u qo'shtirnoqlar, globbing va satr ichidagi har bir buyruqqa ham keng huquq beradi. Agar bitta, aniq install, tee, cp yoki xizmat vositasi yetarli bo'lsa, root shell satriga murojaat qilmang.

Muhit va buyruqni aniqlash

sudo odatda siyosatga ko'ra muhitni filtrlaydi, xavfli o'zgaruvchilarni olib tashlaydi va PATH ni secure_path kabi sozlama bilan almashtirishi mumkin. Shuning uchun oddiy shell’da topilgan alias, funksiya yoki virtual muhit sudo ostida tabiiy ravishda ishlamay qolishi mumkin.

type -a <command>
command -v <command>
sudo -- sh -c 'printf "user=%s home=%s path=%s\n" "$USER" "$HOME" "$PATH"'

Oxirgi buyruq root shell’ni faqat diagnostika uchun ochadi; uning natijasi maqsadli muhitni ko'rsatadi. Production sudoers qoidasida bajariladigan faylni absolyut yo'l bilan yozing. Root kodi ishonchsiz joriy katalog, foydalanuvchi yoza oladigan skript yoki o'zgartirilishi mumkin bo'lgan interpretator/import yo'li orqali ishlashiga yo'l qo'ymang.

To'liq muhitni saqlashni so'raydigan opsiyalar va SETENV sudoers tegi bu himoya chegarasini kengaytirishi mumkin. Faqat haqiqatan kerakli o'zgaruvchilarni ruxsat ro'yxatiga kiritish xavfsizroq. Aniq xatti-harakat amalga oshirish va siyosatga bog'liq — sudo --version, sudo -V yoki lokal man sudoers bilan tekshiring.

Tizim faylini sudoedit bilan tahrirlash

sudo vim /etc/<app>/app.conf muharrirni root sifatida ishga tushiradi. Ko'p muharrirlar shell ochishi, plagin yuklashi yoki tashqi buyruq bajarishi mumkin — bu tahrirlash vazifasining o'ziga kerak bo'lgandan ancha ko'p huquq.

sudoedit yoki sudo -e esa tahrirlash uchun alohida oqimdan foydalanadi:

sudoedit /etc/<app>/app.conf
# the same action:
sudo -e /etc/<app>/app.conf

Sudo odatda faylning vaqtinchalik nusxasini yaratadi, muharrirni chaqiruvchi foydalanuvchi sifatida ishga tushiradi va keyin tahrirlangan versiyani himoyalangan joyga qaytarib nusxalaydi. Siyosat sudoedit va uning yo'llarini alohida cheklashi mumkin.

sudoers siyosatini o'qish

Asosiy siyosat odatda /etc/sudoers da, qo'shimcha qoidalar esa /etc/sudoers.d/ ostida bo'ladi. Soddalashtirilgan qoida:

USER HOST = (RUNAS_USER:RUNAS_GROUP) TAGS: COMMAND

Masalan:

deploy ALL=(root) /usr/bin/systemctl reload catalog.service

Qismlari:

• deploy: huquq oladigan chaqiruvchi.
• ALL: qoida qo'llanadigan hostlar — "barcha buyruqlar" emas.
• (root): buyruq qaysi maqsadli foydalanuvchi sifatida ishlashi.
• /usr/bin/systemctl reload catalog.service: ruxsat berilgan aniq bajariladigan fayl va argumentlar.

Guruh % bilan yoziladi:

%catalog-ops ALL=(root) /usr/bin/systemctl reload catalog.service

Buyruq maydonida ALL ishlatish to'liq administratorlikka yaqin huquq beradi. NOPASSWD autentifikatsiya to'sig'ini butunlay olib tashlaydi; u faqat nazorat ostidagi avtomatlashtirish hisobi, muayyan buyruq va boshqa kompensatsiya qiluvchi nazorat choralari bilan asoslanishi kerak.

Ruxsat berilgan buyruq ham keng bo'lishi mumkin

sudoers bajariladigan fayl nomini ko'rishi bu buyruq qila oladigan hamma narsani izolyatsiya qilmaydi:

• shell, interpretator yoki env deyarli ixtiyoriy kodni ishga tushira oladi;
• muharrir yoki pager shell’ga chiqish (shell escape) imkonini ochishi mumkin;
• paket menejeri hook yoki skriptlarni ishga tushirishi mumkin;
• cp, mv, chmod, chown kabi vositalar muhim faylni almashtirib, bilvosita root’ga olib borishi mumkin;
• xizmatni reload qilish qanchalik xavfsizligi unit’ga, ExecReload ga, muhit fayliga yoki yuklanadigan konfiguratsiyaga kim yoza olishiga bog'liq;
• wildcard argument kutilmagan bo'sh joy yoki opsiyaga ham bilmasdan mos kelishi mumkin.

Demak, "faqat bitta binar fayl" har doim ham eng kam imtiyoz emas. Buyruqning argumentlarini, u o'qiydigan fayllarni, uning plagin/hook’larini va foydalanuvchi yoza oladigan ota kataloglarni birgalikda audit qiling.

visudo bilan xavfsiz tekshirish

/etc/sudoers ni oddiy muharrirda ochish qulflash va sintaksis tekshiruvini chetlab o'tadi. visudo faylni qulflaydi va saqlashdan oldin uning sintaksisini tekshiradi:

sudo visudo
sudo visudo -f /etc/sudoers.d/<rule_name>

Yangi qoidani tizimga o'rnatishdan oldin ham tekshirish mumkin. Bu laboratoriya /etc ga tegmaydi:

mkdir -p ~/lab/root-and-sudo
candidate=~/lab/root-and-sudo/catalog-deploy

printf '%s\n' \
    'deploy ALL=(root) /usr/bin/systemctl reload catalog.service' \
    > "$candidate"
chmod 0600 "$candidate"
visudo -cf "$candidate"
echo $?

Natija amalga oshirishga bog'liq, lekin quyidagiga o'xshaydi:

/home/ali/lab/root-and-sudo/catalog-deploy: parsed OK
0

Agar visudo noto'g'ri qatorni ko'rsatsa, nomzod faylni tuzating; uni /etc/sudoers.d/ ga o'rnatmang. /usr/bin/systemctl maqsadli serverda haqiqiy yo'l ekanini command -v systemctl va tegishli paket egaligini aniqlash vositasi bilan tasdiqlang.

Amaliy vaziyat: deploy hisobi uchun faqat bitta reload

Talab: deploy foydalanuvchisi catalog.service ni reload qila oladi, lekin boshqa hech qanday xizmatni qayta ishga tushira olmasligi va root shell ololmasligi kerak. Ilova konfiguratsiyasi reload’dan oldin alohida tekshiriladi.

Bu sudoers’ga kiritiladigan xavfli production o'zgarishi. Konsol yoki ikkinchi tekshirilgan administrator sessiyasini ochiq saqlang. VM snapshot/konfiguratsiyani boshqarish tizimi va aniq rollback rejasisiz davom etmang.

1. Hisob, buyruq va yashirin bog'liqliklarni tekshiring

getent passwd deploy
command -v systemctl
systemctl show -p FragmentPath -p DropInPaths catalog.service
systemctl cat catalog.service

FragmentPath, drop-in fayllar, ExecReload chaqiradigan skript va xizmat muhit fayllarining egaligi va rejimini tekshiring:

unit_path=$(systemctl show -p FragmentPath --value catalog.service)
stat -c '%A %a %U:%G %n' -- "$unit_path" /usr/bin/systemctl
namei -l "$unit_path"

Agar deploy yoki u boshqaradigan guruh unit’ga, reload skriptiga yoki root o'qiydigan konfiguratsiya fayliga yoza olsa, hatto systemctl reload bilan cheklangan qoida ham root sifatida kod ishga tushirishning bilvosita yo'liga aylanishi mumkin. Avval Ruxsatlar xavfsizligi maqolasiga tayanib, shu egalikni tuzating.

2. Joriy siyosat va rollback nuqtasi

sudo -v
sudo visudo -cf /etc/sudoers
sudo test ! -e /etc/sudoers.d/catalog-deploy
echo $?

Oxirgi holat 0 bo'lsa, nom bo'sh. Agar fayl allaqachon mavjud bo'lsa, uni ustidan yozmang: mazmunini sudo visudo -f bilan ko'ring, konfiguratsiyani boshqarishdagi manbasini toping va alohida zaxira nusxani rejalashtiring.

Yangi qoida uchun kamida asosiy sudoers faylining zaxira nusxasini himoyalangan joyga oling:

sudo cp -a /etc/sudoers /root/sudoers.before-catalog-deploy
sudo stat -c '%A %U:%G %n' /root/sudoers.before-catalog-deploy

Tashkilotingizning zaxira nusxa siyosati /etc/sudoers.d/ ni va har qanday markaziy siyosat manbasini ham qamrab olishi kerak.

3. Nomzodni offline tuzing va tekshiring

candidate=$(mktemp)
printf '%s\n' \
    'deploy ALL=(root) /usr/bin/systemctl reload catalog.service' \
    > "$candidate"
chmod 0600 "$candidate"
visudo -cf "$candidate"

Nomzod oddiy foydalanuvchi katalogida, shuning uchun unga maxfiy ma’lumot yozmang. Natijada parsed OK va 0 chiqish holati bo'lmasa, davom etmang.

4. Drop-in’ni o'rnating va butun siyosatni tekshiring

sudo install -o root -g root -m 0440 \
    "$candidate" /etc/sudoers.d/catalog-deploy
sudo visudo -cf /etc/sudoers

install yangi faylning egasi, guruhi va rejimini bitta qadamda o'rnatadi. /etc/sudoers da drop-in katalogni o'qiydigan include direktivasi bo'lishi kerak. Klassik Sudo'da drop-in fayl nomida . bo'lmasligi va u ~ bilan tugamasligi kerak.

Agar umumiy tekshiruv xato bersa, allaqachon ochiq turgan ikkinchi administrator sessiyasidan qoidani include katalogidan chiqarib oling:

sudo mv /etc/sudoers.d/catalog-deploy /root/catalog-deploy.disabled
sudo visudo -cf /etc/sudoers

Bu rollback yangi qoidani butunlay o'chirmaydi — keyinroq ko'rib chiqish uchun uni /root ga ko'chiradi. Agar mavjud faylni yangilayotgan bo'lsangiz, oldinroq olingan aniq zaxira nusxani tiklang.

5. Siyosat mosligini buyruqni bajarmasdan sinab ko'ring

deploy uchun yangi login sessiyasida:

sudo -l /usr/bin/systemctl reload catalog.service
echo $?
sudo -l /usr/bin/systemctl restart catalog.service
echo $?

Birinchi holat 0, ikkinchisi esa noldan farqli bo'lishi kutiladi. Bu test ikkala buyruqni ham bajarmaydi. Agar natija boshqacha bo'lsa, sudo -ll va include fayllar yordamida boshqa sudoers qoidasidan kelayotgan kengroq ruxsatni qidiring.

6. Nazorat ostidagi reload va tekshirish

Avval ilovaning rasmiy konfiguratsiyani tekshirish buyrug'ini oddiy yoki mos xizmat hisobi sifatida ishga tushiring. Faqat tasdiqlangan texnik xizmat oynasi ichida:

sudo /usr/bin/systemctl reload catalog.service
echo $?
systemctl is-active catalog.service

7. Audit va tozalash

journalctl _COMM=sudo --since today
rm -i -- "$candidate"

sudo amalga oshirilishi va log sozlamasiga qarab yozuvlar journal’da, Ubuntu’da /var/log/auth.log da, RHEL oilasida /var/log/secure da, alohida log faylda yoki markaziy log serverida bo'lishi mumkin. Oddiy sudo logi kim, qaysi buyruqni va qachon so'raganini ko'rsatadi — u buyruq hosil qilgan har bir system call, natija yoki fayl o'zgarishini to'liq qayd etadi deb hisoblamang. I/O loglash alohida siyosatni talab qiladi.

Keng tarqalgan xatolar

Kundalik ishni root shell’da bajarish

Root shell xato ta’sirini butun sessiyaga kengaytiradi. Agar vazifa bitta buyruq bo'lsa, aniq sudo -- command deb yozing; ish tugagach vaqt tamg'asini sudo -k bilan bekor qiling.

sudo root parolini so'raydi deb o'ylash

Standart sudo siyosati odatda chaqiruvchining o'z parolini tekshiradi. su esa odatda maqsadli hisobning paroliga tayanadi. PAM va siyosat buni o'zgartirishi mumkin, shuning uchun taxmin qilish o'rniga so'rov matnini o'qing.

Binar fayl nomini cheklash yetarli deb o'ylash

Ruxsat berilgan bitta buyruq ortidagi interpretator, muharrir, paket menejeri yoki foydalanuvchi yoza oladigan skript ixtiyoriy root amaliga olib kelishi mumkin. Argumentlar, importlar, hook’lar va fayl egaligini ham tekshiring.

sudoers’ni oddiy muharrirda tahrirlash

Sintaksis xatosi administratorlarni sudo'dan butunlay mahrum qilishi mumkin. visudo yoki visudo -f qulflash va sintaksis tekshiruvini ta’minlaydi; shunga qaramay ikkinchi administrator sessiyasi va rollback’ni oldindan tayyorlang.

Qulaylik uchun ALL va NOPASSWD berish

ALL buyruq chegarasini, NOPASSWD esa autentifikatsiya to'sig'ini olib tashlaydi. Avtomatlashtirishga baribir alohida hisob, aniq buyruq va argumentlar, host cheklovi, loglash va hisob ma’lumotlarini himoya qilish kerak.

sudo yo'naltirishni ham root qiladi deb kutish

> va >> ni joriy shell bajaradi. install yoki tee kabi shu ish uchun mo'ljallangan buyruqdan foydalaning; vazifa talab qilgandan ko'proq narsa uchun sudo sh -c bilan root shell ochmang.

sudo muhiti oddiy shell’niki bilan bir xil deb o'ylash

Aliaslar, funksiyalar, PATH, HOME va locale o'zgaruvchilari farq qilishi mumkin. Bajariladigan faylning absolyut yo'lidan va faqat haqiqatan kerakli muhitdan foydalaning; foydalanuvchi yoza oladigan PATH ga tayanmang.

sudo logi sodir bo'lgan hamma narsani isbotlaydi deb o'ylash

Log odatda chaqirilgan buyruqni qayd etadi, lekin u ochgan har bir fayl yoki bajargan har bir tarmoq amalining to'liq izini emas. Muhim holatlarda I/O loglash, audit tizimi, o'zgarishlar qaydlari va ilova loglarini birlashtiring.

sudo muammosini root parolini ochish bilan hal qilish

Ubuntu’da qulflangan root parolini yoqish umumiy hisob ma’lumoti va to'g'ridan-to'g'ri login xavfini oshiradi. Bunga murojaat qilishdan oldin buzilgan sudoers faylini konsol/tiklash rejimi orqali tiklang yoki muayyan siyosatni tuzating.

Mashqlar

1. id, id -u, whoami, HOME va PWD dan joriy identifikator va muhit bo'yicha qisqa hisobot tuzing. Prompt belgisini dalil sifatida ishlatmang.
2. sudo --version, sudo -l va sudo -n -l natijalarini solishtiring. Qaysi amalga oshirish ishlayotganini va interaktiv bo'lmagan tekshiruv nega muvaffaqiyatli yoki muvaffaqiyatsiz bo'lganini tushuntiring.
3. su --login <test_user> va, agar administrator ruxsat bersa, sudo -iu <test_user> o'rtasida id, HOME, PWD va SHELL ni solishtiring. Tizim yoki xizmat hisobi uchun login imkonini ochmang.
4. ~/lab/root-and-sudo da bitta sintaktik jihatdan to'g'ri va bitta buzilgan sudoers nomzodini yarating. Ikkalasini visudo -cf bilan tekshiring; hech birini /etc/sudoers* ga o'rnatmang.
5. "Operator faqat bitta muayyan xizmatni reload qila oladi" degan talab uchun sudoers qoidasi va tahdidlar modelini yozing. Unga bajariladigan fayl, argumentlar, unit, ExecReload, muhit fayli, loglash va rollback’ni kiriting.

Mashqni bajardim deyish uchun: har bir yuqori huquqli amal uchun chaqiruvchini, maqsadli foydalanuvchini, aniq buyruq/argumentlarni, autentifikatsiya usulini, log manbasini va rollback yo'lini ayta olishingiz kerak.

Laboratoriyani tugatganingizda:

find ~/lab/root-and-sudo -xdev -maxdepth 2 \
    -printf '%y %m %u:%g %p\n'

Agar natijada faqat test nomzodlaringiz ko'rinsa:

rm -rI -- ~/lab/root-and-sudo
sudo -k

Manbalar

• Ubuntu Server hujjatlari: user management, root, and sudo-rs: https://ubuntu.com/server/docs/how-to/security/user-management/
• Ubuntu Server hujjatlari: security suggestions: https://ubuntu.com/server/docs/explanation/security/security_suggestions/
• Red Hat Enterprise Linux 9: managing sudo access: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_basic_system_settings/managing-sudo-access_configuring-basic-system-settings
• Sudo qo'llanmasi: sudo(8): https://www.sudo.ws/docs/man/sudo.man/
• Sudo qo'llanmasi: sudoers(5): https://www.sudo.ws/docs/man/sudoers.man/
• Sudo qo'llanmasi: visudo(8): https://www.sudo.ws/docs/man/visudo.man/
• util-linux qo'llanmasi: su(1): https://man7.org/linux/man-pages/man1/su.1.html
• util-linux qo'llanmasi: runuser(1): https://man7.org/linux/man-pages/man1/runuser.1.html
• Linux man-pages: credentials(7): https://man7.org/linux/man-pages/man7/credentials.7.html
• Linux man-pages: capabilities(7): https://man7.org/linux/man-pages/man7/capabilities.7.html
• Linux-PAM System Administrators' Guide: https://www.linux-pam.org/Linux-PAM-html/Linux-PAM_SAG.html
• Linux man-pages: pam.conf(5): https://man7.org/linux/man-pages/man5/pam.conf.5.html
• Linux man-pages: pam_faillock(8): https://man7.org/linux/man-pages/man8/pam_faillock.8.html