SELinux காரணமாக nginx 403: label சரிசெய்வது எப்படி

permissions சரியாக உள்ள file-க்கு nginx ஏன் 403 வழங்குகிறது

permission bits சரியாக உள்ள file-க்கு nginx 403 வழங்கினால், அதற்கான காரணம் பெரும்பாலும் SELinux (security-enhanced Linux) அந்த file-ஐ படிக்க மறுப்பதாகும். வழக்கமான permissions சரிபார்ப்பு வெற்றி பெற்ற பிறகு, SELinux இரண்டாவது விதிகளின் தொகுப்பையும் சரிபார்க்கிறது. web server, web content label கொண்ட files-ஐ மட்டுமே படிக்க அனுமதிக்கப்படுகிறது. உங்கள் file-க்கு வேறு label உள்ளது. எனவே open தோல்வியடைந்து, nginx-க்கு அனுப்ப file கிடைக்காது.

mode-ஐ மட்டும் பார்க்காமல், label-ஐயும் பார்க்கவும்:

ls -ldZ /data/www /data/www/index.html

drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /data/www
-rw-r--r--. root root unconfined_u:object_r:default_t:s0 /data/www/index.html

drwxr-xr-x-க்குப் பிறகு அச்சிடப்படும் dot, அந்த file-க்கு SELinux label இருப்பதைக் குறிக்கிறது. policy-க்கு அந்த path பற்றி இதுவரை தகவல் இல்லாதபோது, அந்த path பெறும் label default_t ஆகும். web server-ன் rules-ல் அந்த type-ஐ படிக்க அனுமதி எதுவும் இல்லை. error log சாதாரண Unix error-ஐக் காட்டுகிறது. அதனால் இது permissions பிரச்சினையாகத் தோன்றுகிறது:

2026/08/11 09:14:02 [error] 1183#1183: *1 open() "/data/www/index.html" failed (13: Permission denied), client: 203.0.113.9, server: _, request: "GET / HTTP/1.1"

சாதாரண மறுப்புக்கும் SELinux மறுப்புக்கும் kernel 13: Permission denied-ஐயே திருப்பி வழங்குகிறது. எனவே எந்த layer மறுத்தது என்பதை முதலில் கண்டறிய வேண்டும். setenforce 0-இல் தொடங்க வேண்டாம்.

Model-ன் உங்களுக்குத் தேவையான பகுதி

SELinux என்பது mandatory access control ஆகும்; இதை பொதுவாக MAC என்று எழுதுவர். ஒவ்வொரு process-உம் ஒரு domain-ல் இயங்கும். Web server-க்கு இது httpd_t போன்றதாக இருக்கும். ஒவ்வொரு file-க்கும் ஒவ்வொரு network port-க்கும் ஒரு type இருக்கும். இது httpd_sys_content_t போன்றதாகும். Policy என்பது domain, type, action ஆகியவற்றின் அனுமதிக்கப்பட்ட சேர்க்கைகளின் பட்டியல். அந்தப் பட்டியலில் இல்லாத அனைத்தும் மறுக்கப்படும். இது classic Unix check-க்குப் பிறகு இயங்கும். எனவே drwxr-xr-x-ல் உள்ள permission bits முதலில் அந்த access-ஐ அனுமதிக்க வேண்டும். இரு layers-உம் அனுமதி அளித்தால்தான் access கிடைக்கும்.

முழு context-ல் colon-களால் பிரிக்கப்பட்ட நான்கு fields இருக்கும். இது system_u:system_r:httpd_t:s0 போன்றது: SELinux user, role, type, level ஆகியவை அவை. Server-ல் நீங்கள் பெரும்பாலும் மூன்றாவது field ஆன type-ஐத்தான் கவனிப்பீர்கள். தற்போதைய values-ஐ இரண்டு commands காட்டும்:

ps -eZ | grep nginx
id -Z

nginx workers-ன் context httpd_t என்று முடியும். உங்கள் login shell unconfined_u:unconfined_r:unconfined_t:s0-ஐக் காட்டும். ஏனெனில் default targeted policy services-ஐ கட்டுப்படுத்தும்; interactive users-ஐ கட்டுப்படுத்தாது. இது தெரிந்திருக்க வேண்டும். ஏனெனில் SELinux, services-ஐ least-privilege users-ன் கீழ் இயக்குவதை மாற்றாது. யாராவது service-க்குள் நுழைந்த பிறகு, அந்த service எதை அணுக முடியும் என்பதை இது கட்டுப்படுத்தும்.

மூன்று modes மற்றும் SELinux கொண்ட images

sestatus
getenforce

Enforcing blocks செய்து அவற்றை logs-ல் பதிவு செய்கிறது. Permissive அனைத்தையும் அனுமதித்து, அது எதை block செய்திருக்கும் என்பதையும் logs-ல் பதிவு செய்கிறது. Disabled எந்த policy-யையும் load செய்யாது. getenforce தற்போதைய mode-ஐ print செய்கிறது. sestatus, reboot பிறகு மீண்டும் செயல்படும் mode-ஐக் குறிப்பிடும் /etc/selinux/config-இலிருந்தும் mode-ஐ print செய்கிறது.

Rocky Linux, AlmaLinux, Fedora மற்றும் RHEL ஆகியவை targeted policy-யுடன் SELinux-ஐ enforcing நிலையில் ship செய்கின்றன. இந்த நான்கும் CentOS வழியாக Rocky Linux மற்றும் AlmaLinux தோன்றுவதற்கு முன் இருந்த ஒரே Red Hat மரபிலிருந்து உருவானவை என்பதால், இந்தப் பொதுவான default தற்செயலானது அல்ல; அது மரபாகப் பெறப்பட்டது. இவற்றில் எதை இயக்குகிறீர்கள் என்பது இந்தப் பக்கத்தில் உள்ள எந்த அம்சத்திலும் மாற்றத்தை ஏற்படுத்தாது. இரண்டும் ஒரே policy மற்றும் ஒரே tools-ஐ ship செய்கின்றன. எனவே, Rocky Linux மற்றும் AlmaLinux இடையே தேர்வு செய்வது security defaults-ஐ அடிப்படையாகக் கொண்டதல்ல; அவற்றின் compatibility promises மற்றும் பழைய CPU support-ஐ அடிப்படையாகக் கொண்டது. Ubuntu மற்றும் Debian இதற்குப் பதிலாக AppArmor-ஐ ship செய்கின்றன. அது வேறுபட்ட mechanism மூலம் அதே பணியைச் செய்கிறது. (கடைசி section-ல் இதைப் பார்க்கலாம்.) அதனால், ஒரே application உங்கள் ஒரு server-ல் clean-ஆக install ஆகி, மற்றொரு server-ல் 403-ஐ return செய்யக்கூடும்.

தேவைப்படும் முன்பே tools-ஐ install செய்யவும்

sudo dnf install -y policycoreutils-python-utils setroubleshoot-server

Minimal image-ல் semanage: command not found இல்லாதது, policycoreutils-python-utils missing ஆக இருப்பதைக் குறிக்கிறது. அந்த package-ல் semanage மற்றும் audit2allow உள்ளன. setroubleshoot-server, sealert-ஐச் சேர்த்து, ஒவ்வொரு denial-க்குமான எளிய ஆங்கிலச் சுருக்கத்தை journal-ல் எழுதுகிறது. புதிய server-ல் இவ்விரண்டையும் install செய்யவும். ஏனெனில் அவை தேவைப்படும் நேரத்தில் ஏற்கனவே ஏதாவது செயலிழந்திருக்கலாம்.

audit log-ல் SELinux denial-ஐப் படிப்பது எப்படி

ஒவ்வொரு மறுப்பும் audit daemon மூலம் AVC (access vector cache) message-ஆக பதிவு செய்யப்படுகிறது:

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

type=AVC msg=audit(1754896442.881:412): avc:  denied  { read } for  pid=1183 comm="nginx" name="index.html" dev="vda1" ino=17203 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0

இந்த முழு நிகழ்வையும் நான்கு fields விளக்குகின்றன. comm என்பது தடுக்கப்பட்ட program. scontext என்பது source context; அதாவது process இயங்கிக்கொண்டிருந்த domain. tcontext என்பது target context; process அணுக முயன்ற பொருளில் இருந்த label. tclass என்பது object-ன் வகை; இங்கு அது file. இவற்றை ஒன்றாகப் படித்தால்: httpd_t-ல் இயங்கிய process, default_t label கொண்ட file-ஐப் படிக்க முயன்றது. அந்தக் கோரிக்கை பதிவு செய்யப்பட்டதோடு மட்டும் நிற்காமல் உண்மையில் தடுக்கப்பட்டது என்பதை permissive=0 காட்டுகிறது.

ausearch எந்த output-உம் காட்டவில்லை என்றால், audit daemon இயங்காமல் இருக்கலாம். அப்போது denial-கள் kernel ring buffer-ல் பதிவாகும்:

sudo journalctl -k | grep -i avc

இப்போது அந்த record-ஐ ஒரு ஆங்கில வாக்கியமாக மாற்றிப் பாருங்கள்:

sudo ausearch -m AVC -ts recent | audit2why
sudo journalctl -t setroubleshoot --since today
sudo sealert -a /var/log/audit/audit.log

audit2why அதே records-ஐப் படித்து, அது கண்டறியும் காரணத்தைக் குறிப்பிடுகிறது: off நிலையில் உள்ள boolean, policy-க்கு பொருந்தாத label, அல்லது எந்த rule-உம் இல்லாத நிலை. sealert முழு log-ஐச் சரிபார்த்து, ஒவ்வொரு denial-க்கும் ஒரு பரிந்துரைக்கப்பட்ட command-ஐக் காட்டுகிறது. அந்தப் பரிந்துரையை ஒரு hint-ஆக மட்டும் கருதுங்கள். Releases-க்கு இடையில் அதன் wording மாறலாம். மேலும், சரியான தீர்வு ஒரே வரியில் label-ஐச் சரிசெய்வதாக இருந்தாலும், sealert சில நேரங்களில் custom policy module-ஐ உருவாக்குமாறு பரிந்துரைக்கலாம்.

மேலும் ஒரு விஷயத்தைத் தெரிந்துகொள்ள வேண்டும். தீங்கற்றவை எனக் கருதப்படும் denial-களை மறைக்கும் dontaudit rules policy-ல் உள்ளன. ஆகவே log காலியாக இருந்தாலும் program தவறாக இயங்கலாம். ஒரு test நடைபெறும் காலத்திற்கு மட்டும் அவற்றை மீண்டும் காட்டச் செய்யுங்கள்:

sudo semodule -DB
# reproduce the problem, then read the log again
sudo semodule -B

semanage fcontext மற்றும் restorecon மூலம் தவறாகக் குறிக்கப்பட்ட path-ஐ சரிசெய்தல்

இரண்டு commands தேவை. அவற்றின் வரிசை முக்கியம். semanage fcontext -a, ஒரு path-க்கு இருக்க வேண்டிய label-ஐ பதிவு செய்கிறது. restorecon, பதிவு செய்யப்பட்ட அந்த default-ஐ disk-ல் உள்ள files-க்கு பயன்படுத்துகிறது.

sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
sudo restorecon -Rv /data/www
ls -ldZ /data/www/index.html

இந்த path ஒரு regular expression ஆகும். (/.*)?, directory-யையும் அதன் கீழ் உள்ள அனைத்தையும் உள்ளடக்கும். document root-க்கு இதுவே தேவை. மாற்றுவதற்கு முன் என்ன மாறும் என்பதைப் பார்க்கவும்: sudo restorecon -Rvn /data/www திட்டமிடப்பட்ட relabel-களை அச்சிடும். ஏனெனில் -n என்பது எந்தச் செயலையும் செய்ய வேண்டாம் என்பதைக் குறிக்கிறது. உண்மையான restorecon இயக்கிய பிறகு, label httpd_sys_content_t எனக் காட்டும்; service restart இல்லாமலேயே 403 மறைந்துவிடும்.

chcon-ஐ test-க்காக மட்டும் பயன்படுத்தவும். chcon -t httpd_sys_content_t index.html label-ஐ நேரடியாக அமைக்கும். அடுத்த restorecon, package update அல்லது முழுமையான relabel அதை மீட்டமைக்கும். காரணம், அந்த path-க்கு வேறு label இருக்க வேண்டும் என்று policy இன்னும் கூறுகிறது. dnf-automatic timer அடிப்படையில் security updates-ஐ பயன்படுத்தும் server-ல், அந்த reset நீங்கள் machine முன் அமர்ந்திருக்கும்போது அல்லாமல் அதன் சொந்த schedule-ல் நடக்கும். எனவே, நீங்கள் கடைசியாக மாற்றிய சில மணி நேரங்களுக்குப் பிறகு site செயலிழக்கலாம். semanage fcontext மட்டுமே நீடிக்கும் version ஆகும். நீங்கள் பதிவு செய்தவற்றை sudo semanage fcontext -l | grep '^/data' மூலம் பட்டியலிடலாம்.

service எழுத வேண்டிய content-க்கு வேறு type தேவை. upload directory அல்லது cache-க்கு httpd_sys_rw_content_t-ஐ பயன்படுத்தவும். அதை அந்த paths-க்கு மட்டும் கட்டுப்படுத்தவும். writable type-ன் கீழ் read-only site இருந்தால், application-க்கு தேவையானதை விட அதிக access வழங்கப்படும்.

Label ஏன் தவறாக இருந்தது? பெரும்பாலும் files எவ்வாறு வந்தன என்பதே காரணம். mv, file-ன் ஏற்கனவே உள்ள label-ஐ வைத்திருக்கும். எனவே /root-லிருந்து வெளியே move செய்யப்பட்ட site, admin_home_t label-உடன் வந்து அதே நிலையில் இருக்கும். சாதாரண cp, புதிய file-க்கு destination directory-ன் default label-ஐ வழங்கும். பொதுவாக இதுவே தேவையானது. ஆனால் cp -a மற்றும் rsync -X, source labels-ஐ file-உடன் copy செய்யும். புதிய top-level directory-க்குள் செய்யப்படும் git clone, default_t-ஐ உருவாக்கும். /usr/share/nginx/html-லிருந்து page சரியாக load ஆகி, உங்கள் சொந்த directory-லிருந்து தோல்வியடைந்தால், இதுவே காரணம்.

boolean மூலம் ஒரு நடத்தை வகையைச் சரிசெய்தல்

சில தோல்விகள் label தொடர்பானவை அல்ல. புதிதாக நிறுவப்பட்ட Rocky அல்லது AlmaLinux box-ல் reverse proxy 502-ஐ வழங்குகிறது. அதன் error log பின்வருமாறு காட்டுகிறது:

2026/08/11 10:02:55 [crit] 1183#1183: *3 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream

உங்கள் upstream சரியாக உள்ளது. httpd_t domain-க்கு outbound network connections-ஐ இயல்பாகத் திறக்க அனுமதி இல்லை. எனவே connect() call loopback interface-ஐ அடையும் முன்பே நிராகரிக்கப்படுகிறது. இந்த முழு நடத்தையையும் ஒரே switch கட்டுப்படுத்துகிறது:

getsebool -a | grep httpd_can_network
sudo setsebool -P httpd_can_network_connect on

-P என்பதே முக்கியமான flag. இது அந்த value-ஐ disk-ல் எழுதுகிறது. -P இல்லையெனில், அடுத்த reboot-இல் இந்த மாற்றம் இழக்கப்படும். இதனால் machine restart ஆகும் வரை மட்டும் service செயல்படும். இயக்கத்தில் உள்ள value-ஐ சேமிக்கப்பட்ட value-க்கு அடுத்ததாகக் காட்டும் semanage boolean -l | grep httpd_can_network_connect மூலம் இதை உறுதிப்படுத்தவும்.

அத்தகைய boolean கிடைக்கும் போது, கையால் எழுதப்பட்ட rule-ஐ விட boolean-ஐப் பயன்படுத்தவும். Booleans distribution policy-யுடன் வழங்கப்படுகின்றன. எனவே அவை பராமரிக்கப்படுகின்றன, ஆவணப்படுத்தப்படுகின்றன, மேலும் அடுத்த நிர்வாகி எளிதாகக் கண்டறிய முடியும். getsebool -a system-ல் உள்ள அனைத்து booleans-ஐயும் பட்டியலிடுகிறது.

Let a service listen on a non-standard port

Ports are labelled too. Move nginx to 8081 and it refuses to start:

nginx: [emerg] bind() to 0.0.0.0:8081 failed (13: Permission denied)

httpd_t may bind ports labelled http_port_t, and 8081 is not one of them. Add it:

sudo semanage port -l | grep -w http_port_t
sudo semanage port -a -t http_port_t -p tcp 8081

Check the list first. Several high ports are already allowed, including 8008 and 8443, and adding one twice fails with ValueError: Port tcp/8081 already defined. If the port already belongs to a different type, change it with semanage port -m -t http_port_t -p tcp 8081 rather than adding it.

The same command is what makes a moved SSH port work. Bind to port 2222 on 0.0.0.0 failed: Permission denied in journalctl -u sshd means 2222 is missing from ssh_port_t, so run sudo semanage port -a -t ssh_port_t -p tcp 2222 before you restart the daemon and close your session. That is the step people skip when they follow a generic guide to hardening SSH on a VPS on a Red Hat family image. SELinux is not a firewall either, so the port still has to be open: sudo firewall-cmd --permanent --add-port=8081/tcp && sudo firewall-cmd --reload here, or ufw on a Debian or Ubuntu image. That --permanent flag carries the same reboot trap as -P on a boolean, and the zones that decide which interfaces a rule applies to are worth reading once in firewalld basics for a Rocky or AlmaLinux VPS.

மாற்ற வேண்டிய boolean மற்றும் label எதுவும் இல்லாதபோது

சாதாரண server-ல் இது அரிதாகவே நிகழும். இந்நிலையில் தவறான நடவடிக்கைகள் சேதத்தை ஏற்படுத்தக்கூடும். Log-ல் உள்ள denials-ஐப் பயன்படுத்தி audit2allow ஒரு policy module-ஐ உருவாக்க முடியும்:

sudo ausearch -m AVC -ts recent -c nginx | audit2allow -M nginx_local
cat nginx_local.te
sudo semodule -i nginx_local.pp

அதை install செய்வதற்கு முன் nginx_local.te-ஐப் படிக்கவும். இதை பாதுகாப்பாக வைத்திருக்க இரண்டு நடைமுறைகள் உதவும். நீங்கள் சரிசெய்யும் ஒரே program-க்கு மட்டும் input-ஐ -c மூலம் filter செய்யவும். தொடர்பில்லாத denials அடங்கிய ஒரு வார கால log-ஐ audit2allow-க்கு pipe செய்தால், அவை அனைத்தும் ஒரே நேரத்தில் அனுமதிக்கப்படும். மேலும், நீங்கள் விளக்க முடியாத denial-இலிருந்து உருவாக்கப்பட்ட module-ஐ ஒருபோதும் install செய்ய வேண்டாம். Server-ல் உள்ள ஒவ்வொரு file-ஐயும் httpd_t படிக்க அனுமதிக்கும் rule-ஐ உருவாக்குவது எளிது; ஆனால் பல மாதங்கள் கழித்து அதைக் கண்டறிவது கடினம். sudo semodule -r nginx_local மூலம் module-ஐ remove செய்யவும்.

Permissive என்பது சரிசெய்தல் அல்ல; இது கண்டறியும் mode

sudo setenforce 0
# reproduce the problem once, all the way through
sudo ausearch -m AVC -ts recent
sudo setenforce 1

Permissive mode access-ஐ அனுமதித்து, அதை log செய்கிறது. இதன் உண்மையான பயன் முழுமைத்தன்மை. Enforcing நிலையில் service முதல் denial-ஐ சந்தித்தவுடன் நிறுத்தப்படும். ஆகவே, அந்தச் சிக்கலைச் சரிசெய்து, service-ஐ மீண்டும் தொடங்கினால் இரண்டாவது denial-ஐச் சந்திக்க நேரிடும். Permissive நிலையில் செயல்பாடு தொடரும். ஒரே run-ல் அனைத்து denial-களையும் log சேகரிக்கும். பின்னர் enforcing நிலைக்குத் திரும்பி, அவற்றை ஒன்றாகச் சரிசெய்யலாம்.

setenforce, /etc/selinux/config-ஐ மாற்றாது. எனவே reboot செய்தால் system மீண்டும் enforcing நிலைக்குத் திரும்பும். இது ஒரு safety net ஆகும். அதனால் setenforce 0-ஐ இயக்கிய நிலையில் வைத்திருப்பதை “fix” எனக் கருதினால், அது மிக மோசமான நேரத்தில் மீண்டும் தோன்றும். நீங்கள் ஒரு service-க்கு மட்டும் பணிபுரியும் போது தற்காலிகமாக கூடுதல் அனுமதி தேவைப்பட்டால், முழு machine-ஐ மாற்றுவதற்குப் பதிலாக அந்த domain-ஐக் குறிக்கவும்: sudo semanage permissive -a httpd_t மற்ற அனைத்தையும் enforcing நிலையில் வைத்திருக்கும்; sudo semanage permissive -d httpd_t அதை மீண்டும் மாற்றும்.

SELinux-ஐ முடக்குவதற்கான செலவு, label-ஐ சரிசெய்வதை விட அதிகம்

SELINUX=disabled-ஐ /etc/selinux/config-ல் அமைப்பது, ஒரே வரி label திருத்தத்திற்கு பதிலாக நிரந்தரமாக பலவீனமான server-ஐ உருவாக்குகிறது. Web application ஒன்று compromised ஆகும் நாளில் இந்த வேறுபாடு தெளிவாகத் தெரியும். Enforcing நிலையில் attacker-ன் code httpd_t-ல் இயங்கும். எனவே அது web content-ஐ படிக்கக்கூடும். ஆனால் /etc/shadow-ஐ படிப்பதற்கோ systemd unit-ஐ எழுதுவதற்கோ Unix user அனுமதித்திருந்தாலும் policy மறுக்கும். Policy எதுவும் load செய்யப்படவில்லை என்றால், அதே code service account-க்கு கிடைக்கும் அனைத்து அனுமதிகளையும் பெறும்.

முடக்குவதற்கான பாதிப்பை பின்னர் சந்திக்க வேண்டியிருக்கும். Policy எதுவும் load செய்யப்படாத நிலையில் உருவாக்கப்படும் புதிய files-க்கு label இருக்காது. இதனால் filesystem, policy-யிலிருந்து படிப்படியாக விலகும். SELinux-ஐ மீண்டும் இயக்கும்போது முழு relabel தேவைப்படும். இல்லையெனில் பல services ஒரே நேரத்தில் fail ஆகலாம்:

sudo fixfiles -F onboot
sudo reboot

இது /.autorelabel-ஐ எழுதுகிறது. அடுத்த boot-இன் போது ஒவ்வொரு filesystem-க்கும் relabel செய்கிறது. பெரிய disk-ல் இதற்கு நீண்ட நேரம் ஆகும். Console முடங்கியதுபோல் தோன்றலாம். எனவே காத்திருக்கக்கூடிய நேரத்தில் இதைத் தொடங்கவும். Machine எப்படியும் shutdown ஆகவிருப்பதால், restart-க்காக ஏற்கனவே queue செய்யப்பட்டுள்ளவற்றை முதலில் பார்ப்பது பயனுள்ளதாக இருக்கும். பழைய kernels மற்றும் libraries memory-ல் இருக்கும் நிலையில் dnf update முடிந்த பிறகு needs-restarting தெரிவிப்பது இதுதான்: dnf update முடிந்த பிறகு needs-restarting தெரிவிக்கும் தகவல். Rocky Linux மற்றும் AlmaLinux 9-ல் config file மட்டும் kernel பகுதியைத் தானாக முடக்காது. SELinux-ஐ முழுமையாக முடக்க documented வழி kernel argument (sudo grubby --update-kernel ALL --args selinux=0) ஆகும். வேறொருவரின் server-ஐ நீங்கள் பொறுப்பேற்கும்போது அந்த command தெரிந்திருப்பது உதவும். 403-க்கான தீர்வு அது அல்ல.

Containers-க்கு மேலும் ஒரு label

Red Hat family host-ல், container processes container_t-ல் இயங்கும்; container_file_t label செய்யப்பட்ட files-ஐ மட்டுமே அவை படிக்க முடியும். Host-லிருந்து செய்யும் bind mount, container-க்குள் Permission denied எனத் தோல்வியடையலாம்; அதே நேரத்தில் host-ல் ls -l முற்றிலும் இயல்பாகத் தோன்றும். :Z suffix, mount-ஐ relabel செய்ய runtime-க்கு அறிவுறுத்துகிறது:

docker run -d -v /data/appdata:/var/lib/app:Z myimage

:Z அந்த directory-ஐ இந்த container-க்கு மட்டும் பயன்படுத்தும் வகையில் label செய்கிறது. :z பல containers இடையே பகிர்வதற்காக label செய்கிறது. பிற services பயன்படுத்தும் directory-ஐ :Z-க்கு கொடுத்தால், அது அந்த directory-ஐ recursive முறையில் relabel செய்யும். இதனால் அந்த services செயலிழக்கும். எனவே containers-க்கு தனிப்பட்ட paths வழங்கவும். இந்த host-ல் engine இன்னும் நிறுவப்படவில்லை என்றால், இந்த distributions-ல் docker command பெரும்பாலும் அந்த பெயரில் இயங்கும் podman ஆக இருக்கும் என்பதை நினைவில் கொள்ளவும். Rocky மற்றும் AlmaLinux install steps இதை நீங்கள் சந்திப்பதற்கு முன்பே சரிசெய்கின்றன. மற்ற setup அனைத்தும் வேறு எந்த image-ஐப் பயன்படுத்தும் setup போலவே இருக்கும். இது VPS-ல் Docker இயக்குதல் பகுதியில் விளக்கப்பட்டுள்ளது.

Ubuntu மற்றும் Debian உங்களுக்கு AppArmor-ஐ வழங்குகின்றன

ஒரே பணி; வடிவமைப்பு வேறு. AppArmor, disk-ல் உள்ள files-க்கு label இடுவதற்குப் பதிலாக, /etc/apparmor.d/-க்கு கீழுள்ள profile-ஐ பயன்படுத்தி ஒரு program-ஐ அதன் executable path அடிப்படையில் கட்டுப்படுத்துகிறது. Relabel செய்ய வேண்டியதில்லை; restorecon-உம் இல்லை. இங்கிருந்து தொடங்கவும்:

sudo aa-status
sudo journalctl -k | grep -i apparmor

ஒரு மறுப்பு apparmor="DENIED" operation="open" profile="/usr/sbin/nginx" name="/data/www/index.html" requested_mask="r" ஆகத் தோன்றும். நடைமுறை ஒரே அமைப்பைக் கொண்டது: denial-ஐப் படிக்கவும், profile-ஐக் கண்டறியவும், rule-ஐ மாற்றவும். sudo apt install apparmor-utils, aa-complain-ஐ வழங்குகிறது (ஒரு profile-க்கு மட்டும் permissive நிலை); அதை மீண்டும் மாற்ற aa-enforce-ஐப் பயன்படுத்தவும். Ubuntu, package செய்யப்பட்ட services-ல் தேர்ந்தெடுக்கப்பட்ட தொகுப்பை மட்டும் கட்டுப்படுத்துகிறது; மீதியை unconfined நிலையில் விடுகிறது. ஆகவே உண்மையில் எது active நிலையில் உள்ளது என்பதை அறிய aa-status-ஐப் படிக்கவும்; ஊகிக்க வேண்டாம்.

இரண்டு systems-க்கும் பொருந்தும் ஒரு பழக்கம் உள்ளது. சரியாகத் தோன்றும் ஏதாவது ஒன்றில் service, Permission denied என்று தெரிவிக்கும்போது, permissions-ஐ மாற்றுவதற்கு முன் security log-ஐப் படிக்கவும். ஒரே permissions பிரச்சினை மீண்டும் மீண்டும் காரணமாக இருப்பது அரிது.

FAQ

file permissions சரியாக இருந்தும் nginx ஏன் 403 வழங்குகிறது?

SELinux read செயல்பாட்டை மறுத்ததே காரணம்; permission bits காரணமல்ல. Web server httpd_t domain-ல் இயங்குகிறது. Web content-க்காக label செய்யப்பட்ட files-ஐ மட்டுமே அது படிக்க முடியும். ஆகவே default_t அல்லது admin_home_t label கொண்ட file மறுக்கப்படுகிறது; nginx-க்கு வழங்குவதற்கு எதுவும் இருக்காது. இதை sudo ausearch -m AVC -ts recent மூலம் உறுதிப்படுத்தலாம். அது scontext, httpd_t-ல் முடிவடைவதையும், tcontext தவறான type-ஐ கொண்டிருப்பதையும் காட்டும். சரியான label-ஐ பதிவு செய்து, அதை இவ்வாறு பயன்படுத்தவும்: sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?" தொடர்ந்து sudo restorecon -Rv /data/www.

Service-ஐ செயல்படச் செய்ய setenforce 0 இயக்குவது பாதுகாப்பானதா?

setenforce 0 ஒரு diagnostic படி மட்டுமே; அது தீர்வு அல்ல. பிரச்சினையை ஒருமுறை மீண்டும் உருவாக்க இதைப் பயன்படுத்தவும். இதனால் log ஒரே முறையில் அனைத்து denials-ஐ சேகரிக்கும். அவற்றை sudo ausearch -m AVC -ts recent மூலம் படித்த பிறகு, sudo setenforce 1 இயக்கி காரணங்களைச் சரிசெய்யவும். Permissive நிலையில் விடப்பட்ட server ஒவ்வொரு denial-ஐயும் log செய்யும்; ஆனால் எதையும் தடுக்காது. இதனால் தேவையற்ற log பதிவுகள் தொடரும், பாதுகாப்பு நீங்கும். நீங்கள் பணிபுரியும் நேரத்தில் ஒரு service-க்கு மட்டும் தற்காலிகமாக அனுமதி தேவைப்பட்டால், sudo semanage permissive -a httpd_t இயக்கவும். இதனால் machine-ன் மீதமுள்ள பகுதி enforcing நிலையில் இருக்கும்.

SELinux enforcing நிலையில் non-standard port-ல் service-ஐ எவ்வாறு இயக்குவது?

அந்த service bind செய்ய அனுமதிக்கப்பட்ட type-க்கு port-ஐச் சேர்க்கவும். 8081-ல் web server-க்கு: sudo semanage port -a -t http_port_t -p tcp 8081. 2222-ல் SSH-க்கு: sudo semanage port -a -t ssh_port_t -p tcp 2222. முதலில் தற்போதைய பட்டியலை sudo semanage port -l | grep -w http_port_t மூலம் சரிபார்க்கவும். ஏற்கனவே பட்டியலில் உள்ள port-ஐ மீண்டும் சேர்த்தால் ValueError: Port tcp/8081 already defined ஏற்படும். இந்தப் படியைத் தவிர்த்தால், வேறு எந்த process-மும் அந்த port-ஐ பயன்படுத்தாவிட்டாலும், daemon startup நேரத்தில் bind() ... Permission denied காரணமாக வெளியேறும்.

Ubuntu-வில் SELinux உள்ளதா?

இல்லை. Ubuntu மற்றும் Debian, executable-ன் path-உடன் இணைக்கப்பட்ட profile-ஐ அமல்படுத்தும் AppArmor-ஐ வழங்குகின்றன. இது files மீது உள்ள labels-க்கு பதிலாக அந்த profile-ஐப் பயன்படுத்துகிறது. அதை sudo aa-status மூலம் சரிபார்த்து, sudo journalctl -k-ல் உள்ள apparmor="DENIED" lines-ஐப் பார்க்கவும். Ubuntu, packaged services-ல் தேர்ந்தெடுக்கப்பட்ட சிலவற்றை மட்டுமே கட்டுப்படுத்துகிறது. ஆகவே பல programs இயல்பாக unconfined நிலையில் இயங்குகின்றன. Rocky Linux மற்றும் AlmaLinux-ல் SELinux enforcing இயல்பாகவே செயல்பாட்டில் இருக்கும். Fedora மற்றும் RHEL-லும் இதே நிலை உள்ளது.