Linux-ի օգտատերեր, խմբեր և թույլտվություններ

01Օգտատերեր, խմբեր և root

Օգտատերը (user) թվային ID-ով (UID) ինքնություն է։ Մարդիկ օգտատերեր են, բայց նաև ծառայությունները․ Ubuntu-ում nginx-ը սովորաբար աշխատում է www-data-ի անունից (RHEL-ում՝ nginx), PostgreSQL-ը՝ postgres-ի։ Խումբը (group) օգտատերերի անվանված հավաքածու է, որը թույլ է տալիս մի քանի օգտատիրոջ տալ նույն հասանելիությունը։ root-ը (UID 0) կարող է ամեն ինչ անել և շրջանցում է թույլտվությունների սովորական ստուգումները, և հենց դրա համար ամեն օր root-ով աշխատել պետք չէ։ Օգտատերերի հաշիվները նշված են /etc/passwd-ում, գաղտնաբառերի hash-երը՝ /etc/shadow-ում (կարդացվում է միայն root-ի կողմից), իսկ խմբերը՝ /etc/group-ում։ id հրամանը ցույց է տալիս, թե ով ես և որ խմբերին ես պատկանում։

1whoami                       # current user
2id                           # uid, gid and all groups
3id www-data                  # who is the web server user?
4getent passwd your_user      # account details
5groups your_user             # group membership
6sudo adduser your_user       # create a user (Debian/Ubuntu, interactive)
7sudo useradd -m -s /bin/bash your_user   # portable, non-interactive
8sudo usermod -aG www-data your_user      # ADD to a group (-a matters!)

02rwx և octal թույլտվությունների ընթերցում

Գործարկիր ls -l, և կտեսնես մոտավորապես այսպիսի բան՝ -rw-r--r-- 1 deploy www-data։ Առաջին նիշը տիպն է (- ֆայլ, d դիրեկտորիա, l link)։ Հետո գալիս են երեք եռյակ՝ տիրոջ իրավունքները, խմբի իրավունքները և մնացած բոլորի իրավունքները։ r-ը read է, w-ն՝ write, x-ը՝ execute։ Դիրեկտորիայի վրա իմաստը փոխվում է․ r-ը թույլ է տալիս ցուցակել անունները, w-ն՝ ներսում ստեղծել և ջնջել ֆայլեր, իսկ x-ը՝ մտնել դրա մեջ և ֆայլերին հասնել ճանապարհով։ Յուրաքանչյուր եռյակ նաև թիվ է՝ r = 4, w = 2, x = 1, իրար գումարած։ Այսպիսով, 644-ը rw-r--r-- է (տերը գրում է, մյուսները կարդում են), 755-ը՝ rwxr-xr-x, 600-ը միայն տիրոջն է, իսկ 640-ը թույլ է տալիս խմբին կարդալ։

• 644՝ սովորական ֆայլեր։ 755՝ դիրեկտորիաներ և script-եր։ 600՝ secret-ներ, ինչպես SSH key-երը և .env ֆայլերը։
• 640 / 750՝ տերը՝ լրիվ, խումբը՝ միայն կարդալ, մյուսները՝ ոչինչ․ լավ է հավելվածի config-ի համար, որը կիսվում է վեբ սերվերի խմբի հետ։
• 777-ը նշանակում է, որ համակարգում ցանկացածը կարող է գրել։ Այն թաքցնում է իրական խնդիրը և անվտանգության անցք է բացում։
• Հատուկ բիթեր՝ setgid-ը դիրեկտորիայի վրա (2775) ստիպում է նոր ֆայլերին ժառանգել դիրեկտորիայի խումբը, sticky bit-ը (1777, ինչպես /tmp-ում) թույլ չի տալիս օգտատերերին ջնջել ուրիշների ֆայլերը։

03chmod, chown և սեփականության շտկում

chmod-ը փոխում է թույլտվությունները, chown-ը՝ տիրոջը և խումբը։ Երկուսն էլ ընդունում են -R ռեկուրսիվ փոփոխությունների համար, ինչը հզոր է և վտանգավոր․ սխալ դիրեկտորիայի վրա անզգույշ chmod -R-ը կարող է կոտրել SSH-ը կամ ամբողջ համակարգը։ Փոքր, ճշգրիտ փոփոխությունների համար օգտագործիր symbolic ռեժիմներ (u+x-ը տիրոջն ավելացնում է execute, g-w-ն խմբից հանում է write), իսկ octal ռեժիմներ՝ երբ ուզում ես ճշգրիտ արդյունք։ Տարածված pattern է ֆայլերին և դիրեկտորիաներին տարբեր ռեժիմներ տալը find-ով, որովհետև դիրեկտորիաներին x պետք է, իսկ սովորական ֆայլերը սովորաբար այն չպետք է ունենան։

1chmod 600 ~/.ssh/id_ed25519          # private key: owner only
2chmod u+x deploy.sh                   # make a script executable
3chmod g-w config.php                  # remove group write
4sudo chown deploy:www-data -R /var/www/app
5# Directories 755, files 644, in one tree
6find /var/www/app -type d -exec chmod 755 {} +
7find /var/www/app -type f -exec chmod 644 {} +
8# Inspect a path permission by permission
9namei -l /var/www/app/storage/logs/app.log

04sudo և /etc/sudoers

sudo-ն մեկ հրաման գործարկում է root-ի (կամ այլ օգտատիրոջ) անունից՝ ստուգելուց հետո, որ դա քեզ թույլատրված է։ Յուրաքանչյուր օգտագործում գրանցվում է log-ում, ինչը հաշվետվողականության համար շատ ավելի լավ է, քան root գաղտնաբառը կիսելը։ Ubuntu-ում sudo խմբի անդամները ստանում են sudo-ի լրիվ իրավունքներ, RHEL-ում խումբը wheel-ն է։ Կանոնները գտնվում են /etc/sudoers-ում և /etc/sudoers.d-ի տակի ֆայլերում։ Երբեք դրանք մի խմբագրիր սովորական խմբագրիչով․ օգտագործիր visudo, որը պահպանելուց առաջ ստուգում է syntax-ը։ Կոտրված sudoers ֆայլը կարող է բոլորին զրկել sudo-ից։ Կարող ես նաև նեղ իրավունքներ տալ, օրինակ՝ deploy օգտատիրոջը թույլ տալ առանց գաղտնաբառի restart անել մեկ ծառայություն և ուրիշ ոչինչ։ Ubuntu-ի վերջին թողարկումները գալիս են sudo-rs-ով՝ memory-safe վերագրված տարբերակով՝ նույն հրամաններով և config-ով։

1sudo usermod -aG sudo your_user     # full sudo (wheel on RHEL)
2sudo -l                             # what am I allowed to run?
3sudo -u postgres psql               # run as another user
4sudo visudo -f /etc/sudoers.d/deploy
5# Content of /etc/sudoers.d/deploy:
6deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp.service

05umask, ծառայությունների օգտատերեր և ACL-ներ

umask-ը որոշում է նոր ֆայլերի լռելյայն թույլտվությունները՝ բիթեր հանելով։ Տարածված լռելյայն 022-ը նոր ֆայլերին տալիս է 644, իսկ նոր դիրեկտորիաներին՝ 755․ 002 umask-ը տալիս է 664 և 775, ինչը հարմար է խումբ կիսող թիմերի համար։ Հավելվածների համար ստեղծիր առանձին system user առանց login shell-ի և նրան տեր դարձրու միայն այն բանի, ինչ հավելվածը պետք է գրի։ ACL-ները (access control lists) owner/group/other մոդելի վրա լրացուցիչ կանոններ են ավելացնում, օրինակ՝ ևս մեկ օգտատիրոջ write հասանելիություն տալ մեկ դիրեկտորիայի։ Դրանք հարմար են, բայց թաքնված են արագ ls -l-ից (փնտրիր +-ը mode-ի վերջում), ուստի օգտագործիր դրանք խնայողաբար և փաստաթղթավորիր։

1umask                                   # show current mask, e.g. 0022
2sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
3sudo chown -R myapp:myapp /var/lib/myapp
4# ACL: let www-data write to one directory, now and for new files
5sudo setfacl -R -m u:www-data:rwX /var/www/app/storage
6sudo setfacl -R -d -m u:www-data:rwX /var/www/app/storage
7getfacl /var/www/app/storage

06Դասական bug-ը՝ վեբ սերվերը չի կարողանում գրել

Տիպիկ դեպք՝ PHP կամ Node հավելվածը լոկալ աշխատում է, բայց production-ում log-ում գրում է «Permission denied», երբ cache, log-եր կամ upload-ներ է գրում։ Պատճառը գրեթե միշտ այն է, որ կոդը deploy է արվել մի օգտատիրոջ կողմից (deploy կամ root), մինչդեռ հավելվածն աշխատում է մեկ ուրիշի անունից (www-data կամ PHP-FPM pool-ի օգտատեր)։ Լուծումը 777-ը չէ։ Փոխարենը պարզիր, թե որ օգտատիրոջ անունից է աշխատում պրոցեսը, կոդը թող պատկանի deploy օգտատիրոջը և լինի read-only հավելվածի համար, իսկ հավելվածին write հասանելիություն տուր միայն այն դիրեկտորիաներին, որոնց դա իսկապես պետք է, օրինակ՝ Laravel-ում storage-ին և bootstrap/cache-ին։ setgid բիթը նոր ֆայլերը պահում է ճիշտ խմբում։ Հիշիր նաև, որ root-ով deploy անելը կամ artisan հրամաններ գործարկելը կարող է ստեղծել root-ին պատկանող cache ֆայլեր, որոնք հավելվածը հետո չի կարող վերագրել։

1ps -o user,pid,cmd -C php-fpm8.3     # which user runs PHP? (adjust version)
2ps -o user,pid,cmd -C node
3cd /var/www/app
4sudo chown -R deploy:www-data .
5sudo chmod -R 750 .
6sudo chmod -R 2775 storage bootstrap/cache     # group write + setgid
7sudo find storage bootstrap/cache -type f -exec chmod 664 {} +
8sudo -u www-data php artisan cache:clear       # run as the app user, not root

07Ինչպես է kernel-ն իրականում ստուգում հասանելիությունը

Յուրաքանչյուր open-ի ժամանակ kernel-ը համեմատում է պրոցեսի effective UID-ն և նրա խմբերը (հիմնականը և լրացուցիչները) ֆայլի սեփականատիրոջ և խմբի հետ։ Ստուգումն ընտրում է ճիշտ մեկ դաս՝ հերթականությամբ․ եթե դու սեփականատերն ես, հաշվի են առնվում միայն owner բիթերը, հակառակ դեպքում, եթե խմբերիցդ մեկը համընկնում է, միայն group բիթերը, հակառակ դեպքում՝ other բիթերը։ Դասերը չեն գումարվում, ուստի 0077 mode-ով ֆայլը մերժում է իր իսկ սեփականատիրոջը, թեև բոլոր մյուսները կարող են կարդալ այն։ Ֆայլին հասնելու համար անհրաժեշտ է նաև x (search) թույլտվություն ճանապարհի յուրաքանչյուր դիրեկտորիայի վրա, ինչը namei -l-ը ցույց է տալիս մեկ հայացքով։ Ֆայլի ջնջումը կամ վերանվանումը կախված է դիրեկտորիայի, ոչ թե ֆայլի գրելու թույլտվությունից։ Root-ը շրջանցում է այս ստուգումների մեծ մասը ոչ թե կախարդանքով, այլ capability-ների միջոցով, ինչպես CAP_DAC_OVERRIDE-ը, իսկ աշխատող պրոցեսը պահպանում է login-ի պահին ունեցած խմբերի ցուցակը, ինչի պատճառով նոր խմբին անդամակցությունը նոր session է պահանջում։

1cat /proc/self/status | grep -E '^(Uid|Gid|Groups)'   # real/effective IDs
2chmod 077 test.txt && cat test.txt      # owner denied: only owner bits apply
3namei -l /srv/app/shared/.env           # x needed on every directory
4sudo -u www-data test -r /srv/app/shared/.env && echo readable
5newgrp www-data                          # pick up a new group without relogin

08setuid, setgid և capability-ներ

Setuid ծրագիրն աշխատում է իր սեփականատիրոջ, այլ ոչ թե կանչողի արտոնություններով․ passwd-ը և sudo-ն setuid root են, որպեսզի սովորական օգտատերերը կարողանան վերահսկվող ձևով փոխել պաշտպանված ֆայլերը։ Յուրաքանչյուր setuid-root binary հարձակման մակերես է, ուստի աուդիտ արա դրանք և երբեք մի դիր այդ բիթը script-երի կամ սեփական գործիքների վրա։ Linux capability-ները root-ի ուժը բաժանում են մոտ քառասուն մասի, ուստի ծրագիրը կարող է ստանալ միայն մեկը․ cap_net_bind_service-ը թույլ է տալիս non-root պրոցեսին bind անել 1024-ից ցածր port-եր, cap_net_raw-ը թույլ է տալիս ping-ին raw փաթեթներ ուղարկել։ Ֆայլային capability-ները դրվում են setcap-ով, իսկ systemd-ն կարող է դրանք տալ ծառայությանը AmbientCapabilities-ով՝ մնացած ամեն ինչը հանելով CapabilityBoundingSet-ով։ Ֆայլային համակարգերը կարող են նաև mount արվել nosuid, nodev և noexec օպցիաներով, ինչը էժան hardening քայլ է upload-ի և ժամանակավոր դիրեկտորիաների համար, որոնք երբեք չպետք է գործարկվող ծրագրեր պարունակեն։

1find / -xdev -perm -4000 -type f 2>/dev/null   # setuid binaries
2getcap -r /usr/bin 2>/dev/null                 # files with capabilities
3sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/myserver
4# In a systemd unit, instead of setcap:
5#   AmbientCapabilities=CAP_NET_BIND_SERVICE
6#   CapabilityBoundingSet=CAP_NET_BIND_SERVICE
7findmnt -o TARGET,OPTIONS /tmp                  # check nosuid,noexec

09Երբ mode-երը ճիշտ են, բայց հասանելիությունը դեռ մերժվում է

Եթե ls -l-ը կատարյալ է թվում, իսկ հավելվածը դեռ ստանում է EACCES, դասական մոդելից վեր ինչ-որ բան «ոչ» է ասում։ Mandatory access control-ը սովորական կասկածյալն է․ Ubuntu-ում AppArmor-ը սահմանափակված ծրագրերին թույլ է տալիս միայն իրենց profile-ում նշված ճանապարհները, իսկ RHEL-ում SELinux-ը label է դնում յուրաքանչյուր ֆայլի և պրոցեսի վրա և մերժում է այն ամենը, ինչ policy-ն չի թույլատրում՝ անկախ սեփականատիրոջից և mode-ից։ SELinux-ում web root-ի մեջ տեղափոխված (ոչ թե պատճենված) ֆայլը պահպանում է իր հին label-ը, ինչը 403 սխալների դասական պատճառ է․ restorecon-ը շտկում է դա։ Այլ թաքնված շերտեր՝ chattr +i-ով դրված immutable ատրիբուտը, որը արգելափակում է նույնիսկ root-ին, մինչև այն հանվի, read-only կամ noexec mount-եր, ACL mask-եր, որոնք սահմանափակում են group գրառումները, և container-ներում՝ user namespace-ներ, որոնք container-ի root-ը քարտեզագրում են host-ի ոչ արտոնյալ UID-ի։ Ստուգիր սրանք՝ մինչև mode-երին ձեռք տալը։

1sudo aa-status                        # AppArmor profiles in enforce mode
2sudo journalctl -k | grep -i apparmor  # AppArmor denials
3ls -Z /var/www/html                    # SELinux labels (RHEL family)
4sudo ausearch -m avc -ts recent        # SELinux denials
5sudo restorecon -Rv /var/www/html      # reset labels to policy defaults
6lsattr /etc/resolv.conf                # 'i' = immutable
7getfacl /srv/app/storage | grep mask   # ACL mask limiting entries

10UID-ները container-ներում և volume-ներում

Kernel-ը պահում է թվեր, ոչ թե անուններ։ UID 1000-ին պատկանող ֆայլը պատկանում է նրան, ով ունի UID 1000 ընթացիկ օգտատերերի բազայում, իսկ այն տարբեր է host-ի և container image-ի միջև։ Դրա համար են bind-mount արված դիրեկտորիաները հաճախ ցույց տալիս տարօրինակ սեփականատերեր կամ դառնում անհասանելի գրելու համար․ container-ի պրոցեսն աշխատում է որպես UID 33 (www-data Debian image-ներում) կամ 1000 (node պաշտոնական Node image-ներում), մինչդեռ host-ի ֆայլերը պատկանում են քո deploy օգտատիրոջը։ Լուծումները՝ ամենապարզից․ container-ը գործարկիր host-ի UID-ով և GID-ով (user: "1000:1000" Compose-ում), volume-ը chown արա container-ի UID-ին, կամ օգտագործիր named volume-ներ, որոնք Docker-ը ինքն է նախապատրաստում։ Rootless Docker-ը և Podman-ը ավելացնում են user namespace-ներ, ուստի container-ի root-ը host-ում քարտեզագրվում է բարձր ոչ արտոնյալ UID-ի, ինչը բարելավում է անվտանգությունը, բայց փոխում է սկավառակի վրա տեսանելի թվերը։ systemd-ի DynamicUser-ը նույն ոգով յուրաքանչյուր ծառայության համար ժամանակավոր UID է հատկացնում։

1docker compose exec app id                  # UID inside the container
2stat -c '%u:%g %n' ./storage                # numeric owner on the host
3# docker-compose.yml
4#   services:
5#     app:
6#       user: "1000:1000"                   # match the host deploy user
7cat /etc/subuid                             # ranges for rootless containers