nginx 403: SELinux label సమస్యను ఎలా పరిష్కరించాలి

సరైన permissions ఉన్న ఫైల్‌కు nginx 403 ఎందుకు ఇస్తుంది

ఫైల్ permission bits సరిగ్గా ఉన్నప్పటికీ nginx 403 ఇస్తే, దానికి దాదాపు ఎల్లప్పుడూ SELinux (security-enhanced Linux) read ను నిరాకరించడమే కారణం. సాధారణ permissions తనిఖీ పూర్తయిన తర్వాత SELinux మరో నియమాల సమితిని తనిఖీ చేస్తుంది. web server web content label ఉన్న ఫైళ్లను మాత్రమే చదవగలదు. మీ ఫైల్‌కు వేరే label ఉండటంతో open విఫలమవుతుంది, అందువల్ల nginx పంపడానికి ఎలాంటి కంటెంట్ ఉండదు.

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 ఆ ఫైల్‌కు SELinux label ఉందని సూచిస్తుంది. policy కు ఒక path గురించి ఎప్పుడూ తెలియనప్పుడు దానికి default_t వస్తుంది. web server నియమాల్లో ఆ 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 తో ప్రారంభించవద్దు.

మీకు అవసరమైన మోడల్‌లోని భాగం

SELinux అనేది సాధారణంగా MAC అని పిలిచే mandatory access control విధానం. ప్రతి process ఒక domain లో నడుస్తుంది. ఉదాహరణకు web server కోసం httpd_t ఉపయోగించబడుతుంది. ప్రతి file మరియు ప్రతి network port కు ఒక type ఉంటుంది. ఉదాహరణకు httpd_sys_content_t. Domain, type, action కలయికలకు అనుమతించబడిన వాటి జాబితానే policy. ఆ జాబితాలో లేనివన్నీ నిరాకరించబడతాయి. ఇది classic Unix check తర్వాత అమలవుతుంది. కాబట్టి drwxr-xr-x లోని permission bits ముందుగా access ను అనుమతించాలి. రెండు layers కూడా అనుమతి ఇవ్వాలి.

పూర్తి context లో colonలతో వేరు చేసిన నాలుగు fields ఉంటాయి. ఉదాహరణకు system_u:system_r:httpd_t:s0. అవి SELinux user, role, type, level. Serverపై మీరు దాదాపు ఎల్లప్పుడూ మూడో field అయిన type పైనే దృష్టి పెడతారు. ప్రస్తుత విలువలను చూపడానికి ఈ రెండు 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 లోకి చొరబడిన తర్వాత అది ఏ వనరులను చేరుకోగలదో SELinux పరిమితం చేస్తుంది.

మూడు మోడ్‌లు మరియు SELinux ఉన్న images

sestatus
getenforce

Enforcing అభ్యర్థనలను నిరోధించి logs నమోదు చేస్తుంది. Permissive ప్రతిదానికీ అనుమతిస్తుంది మరియు నిరోధించి ఉండాల్సిన వాటిని logs లో నమోదు చేస్తుంది. Disabled ఎలాంటి policy ని లోడ్ చేయదు. ప్రస్తుత mode ను getenforce చూపిస్తుంది. sestatus mode తో పాటు /etc/selinux/config నుంచి వచ్చిన mode ను కూడా చూపిస్తుంది. Reboot తర్వాత తిరిగి వచ్చే mode ఇదే.

Rocky Linux, AlmaLinux, Fedora మరియు RHEL, targeted policy తో SELinux ను Enforcing mode లో విడుదల చేస్తాయి. ఈ నాలుగు పంపిణీలకు ఒకే default ఉండటం యాదృచ్ఛికం కాదు. Rocky Linux మరియు AlmaLinux అందుబాటులోకి రాకముందు CentOS ద్వారా కొనసాగిన ఒకే Red Hat వారసత్వం నుంచి ఇవన్నీ అభివృద్ధి చెందాయి. మీరు ఈ రెండింటిలో ఏదిని నడిపినా ఈ పేజీలోని విషయాలపై తేడా ఉండదు. రెండూ ఒకే policy మరియు ఒకే tools ను అందిస్తాయి. అందువల్ల Rocky Linux మరియు AlmaLinux మధ్య ఎంపిక security defaults పై కాకుండా వాటి compatibility హామీలు మరియు పాత CPU మద్దతుపై ఆధారపడి ఉంటుంది. Ubuntu మరియు Debian బదులుగా AppArmor ను అందిస్తాయి. ఇది వేరే విధానంతో అదే పని చేస్తుంది. చివరి section లో దాని గురించి వివరించబడుతుంది. అందువల్ల ఒకే application మీ servers లో ఒకదానిపై సులభంగా install కావచ్చు, మరొకదానిపై 403 ను తిరిగి ఇవ్వవచ్చు.

మీకు అవసరం ఏర్పడకముందే సాధనాలను ఇన్‌స్టాల్ చేయండి

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

కనిష్ట image పై semanage: command not found ఉంటే, policycoreutils-python-utils అందుబాటులో లేదని అర్థం: ఆ package లో semanage మరియు audit2allow ఉంటాయి. setroubleshoot-server, sealert ను జోడించి, ప్రతి denial కు సంబంధించిన సులభమైన ఆంగ్ల సారాంశాన్ని journal లో వ్రాస్తుంది. కొత్త server పై ఈ రెండింటినీ ఇన్‌స్టాల్ చేయండి. ఎందుకంటే మీకు అవి అవసరమయ్యే సమయానికి ఏదో ఒకటి ఇప్పటికే విఫలమై ఉంటుంది.

Audit log లో SELinux denial ను ఎలా చదవాలి

ప్రతి తిరస్కరణను audit daemon AVC (access vector cache) సందేశంగా నమోదు చేస్తుంది:

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 ను చదవడానికి ప్రయత్నించింది. ఆ అభ్యర్థన కేవలం log చేయబడకుండా నిజంగా నిరోధించబడిందని permissive=0 చూపిస్తుంది.

ausearch ఏ output ఇవ్వకపోతే audit daemon నడుస్తూ ఉండకపోవచ్చు. అప్పుడు denials kernel ring buffer లో నమోదవుతాయి:

sudo journalctl -k | grep -i avc

ఇప్పుడు record ను ఒక English వాక్యంగా మార్చండి:

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 మారుతుంది. అలాగే, ఒక line label fix సరైన పరిష్కారం అయినప్పటికీ sealert కొన్నిసార్లు custom policy module ను సూచిస్తుంది.

ఇంకో విషయం తెలుసుకోవాలి. Policy లో harmless గా భావించిన denials ను దాచే dontaudit rules ఉంటాయి. అందువల్ల log ఖాళీగా ఉన్నప్పటికీ program సరిగ్గా పనిచేయకపోవచ్చు. ఒక test కొనసాగినంతసేపు వాటిని మళ్లీ చూపించండి:

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

semanage fcontext మరియు restorecon తో తప్పుగా ఉన్న path label ను సరిచేయడం

ఇందుకు రెండు 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 అమలు చేయబోయే relabels ను చూపిస్తుంది, ఎందుకంటే -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 దాన్ని reset చేస్తాయి, ఎందుకంటే ఆ path కు వేరే label ఉండాలని policy ఇప్పటికీ చెబుతుంది. dnf-automatic నిర్ణీత సమయానికి security updates అమలు చేసే system లో, మీరు machine ముందు కూర్చున్న సమయంలో కాకుండా దాని స్వంత schedule ప్రకారం ఆ reset జరుగుతుంది. అందువల్ల మీరు చివరిగా మార్చిన విషయానికి కొన్ని గంటల తర్వాత 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 నుంచి తరలించిన 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 నుంచి విఫలమైతే, కారణం ఇదే.

బూలియన్‌తో ఒక ప్రవర్తనా తరగతిని సరిచేయడం

కొన్ని వైఫల్యాలు label సమస్యలు కావు. కొత్త Rocky లేదా AlmaLinux సిస్టమ్‌లో 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 పనిచేస్తుంది. semanage boolean -l | grep httpd_can_network_connect తో నిర్ధారించండి. ఇది running value ను stored value పక్కన చూపిస్తుంది.

అటువంటి boolean అందుబాటులో ఉన్నప్పుడు, చేతితో రాసిన rule కంటే దానినే ఉపయోగించండి. Booleans distribution policy తో వస్తాయి. అందువల్ల అవి నిర్వహించబడతాయి, document చేయబడతాయి, తరువాతి వ్యక్తికి సులభంగా కనిపిస్తాయి. 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ను audit2allowకు pipe చేస్తే, అవన్నీ ఒకేసారి అనుమతించబడతాయి. మీరు వివరించలేని denial ఆధారంగా రూపొందించిన moduleను ఎప్పుడూ install చేయవద్దు. httpd_tకు మొత్తం systemలోని ప్రతి fileను చదివే అనుమతి ఇవ్వడం సులభంగా generate చేయవచ్చు. కానీ నెలల తర్వాత దాన్ని గుర్తించడం కష్టం. sudo semodule -r nginx_localతో moduleను remove చేయండి.

Permissive అనేది నిర్ధారణ మోడ్ మాత్రమే, పరిష్కారం కాదు

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

Permissive మోడ్ access ను అనుమతించి, దాన్ని log చేస్తుంది. దీని అసలు ప్రయోజనం సమగ్రత. Enforcing మోడ్‌లో service మొదటి denial వద్ద ఆగిపోతుంది. అందువల్ల మీరు దాన్ని పరిష్కరించి, service ను restart చేసిన తర్వాత రెండో denial ను ఎదుర్కొంటారు. Permissive మోడ్‌లో run కొనసాగుతుంది. ఒకే pass లో log ప్రతి denial ను సేకరిస్తుంది. తరువాత మీరు మళ్లీ enforcing మోడ్‌కు మారి, వాటన్నింటినీ కలిసి పరిష్కరించవచ్చు.

setenforce, /etc/selinux/config ను మార్చదు. అందువల్ల reboot తర్వాత system మళ్లీ enforcing మోడ్‌లోకి వస్తుంది. ఇది ఒక safety net. అందుకే setenforce 0 తో చేసిన "పరిష్కారం" అత్యంత అననుకూల సమయంలో మళ్లీ కనిపిస్తుంది. మీరు ఒక service పై పని చేస్తున్నప్పుడు దానికి తాత్కాలికంగా అదనపు అనుమతి అవసరమైతే, మొత్తం machine కు కాకుండా ఆ domain ను మాత్రమే గుర్తించండి: sudo semanage permissive -a httpd_t మిగతా అన్నింటినీ enforcing మోడ్‌లోనే ఉంచుతుంది, sudo semanage permissive -d httpd_t దాన్ని తిరిగి మారుస్తుంది.

లేబుల్‌ను సరిచేయడం కంటే SELinux ను నిలిపివేయడానికి ఎక్కువ ఖర్చవుతుంది

/etc/selinux/config లో SELINUX=disabled ను సెట్ చేయడం ద్వారా ఒక పంక్తి లేబుల్ సవరణకు బదులుగా సర్వర్‌ను శాశ్వతంగా బలహీనపరుస్తారు. వెబ్ అప్లికేషన్ breach అయిన రోజున ఈ తేడా స్పష్టంగా కనిపిస్తుంది. enforcing స్థితిలో దాడిచేసినవారి కోడ్ httpd_t లో నడుస్తుంది. అందువల్ల అది వెబ్ కంటెంట్‌ను చదవవచ్చు. అయితే Unix user అనుమతించినా, /etc/shadow చదవడం లేదా systemd unit రాయడం policy ద్వారా నిరాకరించబడుతుంది. Policy ఏదీ load చేయకపోతే, అదే కోడ్‌కు service account కలిగి ఉన్న అన్ని అనుమతులు లభిస్తాయి.

దీన్ని నిలిపివేయడం వల్ల తరువాత కూడా మీరు మూల్యం చెల్లించాలి. Policy ఏదీ load కానప్పుడు కొత్త files ఎలాంటి label లేకుండా సృష్టించబడతాయి. అందువల్ల filesystem policyకి అనుగుణంగా ఉండదు. తరువాత SELinux ను మళ్లీ enable చేయాలంటే పూర్తి relabel అవసరం అవుతుంది. లేకపోతే అనేక services ఒకేసారి fail అవుతాయి:

sudo fixfiles -F onboot
sudo reboot

ఇది /.autorelabel ను రాస్తుంది. తరువాతి boot సమయంలో ప్రతి filesystem కు relabel చేస్తుంది. పెద్ద disk పై దీనికి చాలా సమయం పడుతుంది. Console నిలిచిపోయినట్లు కనిపించవచ్చు. కాబట్టి వేచి ఉండగల సమయంలో దీన్ని ప్రారంభించండి. Machine ఏమైనప్పటికీ shutdown అవుతున్నందున, restart కోసం ఇప్పటికే queueలో ఉన్న ఇతర అంశాలను ముందుగా పరిశీలించడం ఉపయోగకరం. dnf update తర్వాత పాత kernels మరియు libraries memoryలో మిగిలితే needs-restarting నివేదించే అంశాలు ఇవే. Rocky Linux మరియు AlmaLinux 9లో config file ఇకపై kernel భాగాన్ని స్వయంగా switch off చేయదు. SELinux ను పూర్తిగా disable చేయడానికి documented విధానం kernel argument (sudo grubby --update-kernel ALL --args selinux=0) ఉపయోగించడం. మీరు వేరొకరి serverను స్వీకరించినప్పుడు ఆ command తెలుసుకోవడం ఉపయోగపడుతుంది. ఇది 403కు పరిష్కారం కాదు.

కంటైనర్లు మరో label ను జోడిస్తాయి

Red Hat కుటుంబానికి చెందిన hostలో container processes container_t లో నడుస్తాయి. అవి container_file_t label కలిగిన files ను మాత్రమే చదవగలవు. Host నుంచి bind mount చేస్తే, hostలో ls -l సరిగ్గా కనిపించినప్పటికీ, containerలో Permission denied error వస్తుంది. :Z suffix runtime కు mount ను relabel చేయమని చెబుతుంది:

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

:Z ఆ directoryని ఈ container కోసం మాత్రమే label చేస్తుంది. :z దానిని containers మధ్య share చేయడానికి label చేస్తుంది. ఇతర services ఉపయోగించే directoryని :Z కు ఇస్తే, అది ఆ directoryని recursively relabel చేస్తుంది. దీనివల్ల ఆ services పనిచేయడం ఆగిపోతుంది. కాబట్టి containers కోసం ప్రత్యేక paths ఉపయోగించండి. ఈ hostలో engine ఇంకా లేకపోతే, ఈ distributionsలోని docker command తరచుగా ఆ పేరుతో పనిచేసే podman కావచ్చని గుర్తుంచుకోండి. Rocky మరియు AlmaLinux install steps లో ఈ సమస్య ఎదురయ్యే ముందు దాన్ని పరిష్కరిస్తారు. మిగిలిన setup ఇతర imageల మాదిరిగానే ఉంటుంది. దీనిని VPSపై Dockerను నడపడం లో వివరించాం.

Ubuntu మరియు Debian మీకు AppArmor ను అందిస్తాయి

పని ఒకటే, రూపకల్పన మాత్రం భిన్నంగా ఉంటుంది. AppArmor ఒక ప్రోగ్రామ్‌ను దాని executable path ఆధారంగా పరిమితం చేస్తుంది. దీనికి /etc/apparmor.d/ కింద ఉన్న profile ను ఉపయోగిస్తుంది. డిస్క్‌లోని ఫైళ్లకు మళ్లీ label ఇవ్వాల్సిన అవసరం ఉండదు. అలాగే 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 ప్యాకేజీగా అందించే ఎంపిక చేసిన సేవలను మాత్రమే పరిమితం చేస్తుంది. మిగతా సేవలను పరిమితం చేయదు. కాబట్టి వాస్తవంగా ఏవి active గా ఉన్నాయో తెలుసుకోవడానికి aa-status చదవండి. ఊహించవద్దు.

రెండు సిస్టమ్‌లలోనూ ఒకే అలవాటు ఉపయోగపడుతుంది. సరైనదిగా కనిపించే ఏదైనా అంశంపై ఒక సేవ Permission denied అని నివేదిస్తే, permissions మార్చే ముందు security log చదవండి. ఒకే సమస్య permissions లో రెండుసార్లు ఉండటం చాలా అరుదు.

FAQ

nginx file permissions సరైనప్పటికీ 403 ఎందుకు ఇస్తుంది?

SELinux read అనుమతిని నిరాకరించింది; permission bits సమస్య కాదు. Web server httpd_t domain లో నడుస్తుంది. Web content కోసం label చేసిన files ను మాత్రమే అది చదవగలదు. అందువల్ల default_t లేదా admin_home_t label ఉన్న file నిరాకరించబడుతుంది. nginx కు అందించడానికి file ఉండదు. దీన్ని 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.

సేవ పనిచేయడానికి setenforce 0 నడపడం సురక్షితమేనా?

setenforce 0 ఒక diagnostic step మాత్రమే; పరిష్కారం కాదు. సమస్యను ఒక్కసారి పునరుత్పత్తి చేయడానికి దీన్ని ఉపయోగించండి. అప్పుడు log ఒకే pass లో అన్ని denials ను సేకరిస్తుంది. వాటిని sudo ausearch -m AVC -ts recent తో చదవండి. తరువాత sudo setenforce 1 నడిపి కారణాలను సరిచేయండి. Permissive mode లో server ఉంచితే ప్రతి denial ను log చేస్తుంది, కానీ ఏదీ నిరోధించదు. అందువల్ల noise మిగిలి, protection తొలగిపోతుంది. మీరు పని చేస్తున్నప్పుడు ఒక సేవకు తాత్కాలికంగా అవకాశం ఇవ్వాల్సి వస్తే sudo semanage permissive -a httpd_t నడపండి. అప్పుడు మిగిలిన machine enforcing mode లోనే ఉంటుంది.

SELinux enforcing mode లో non-standard port పై సేవను ఎలా నడపాలి?

ఆ సేవ 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. ముందుగా ప్రస్తుత list ను sudo semanage port -l | grep -w http_port_t తో పరిశీలించండి. ఎందుకంటే ఇప్పటికే list లో ఉన్న port తో ValueError: Port tcp/8081 already defined విఫలమవుతుంది. ఈ step లేకపోతే port ను మరే process ఉపయోగించకపోయినా daemon startup సమయంలో bind() ... Permission denied తో నిష్క్రమిస్తుంది.

Ubuntu లో SELinux ఉందా?

లేదు. Ubuntu మరియు Debian AppArmor ను ship చేస్తాయి. ఇది files పై labels కు బదులుగా executable path కు అనుసంధానమైన profile ను enforce చేస్తుంది. దీన్ని sudo aa-status తో తనిఖీ చేయండి. sudo journalctl -k లో apparmor="DENIED" lines కోసం చూడండి. Ubuntu ఎంపిక చేసిన packaged services సముదాయాన్ని మాత్రమే confine చేస్తుంది. అందువల్ల అనేక programs default గా unconfined గా నడుస్తాయి. Rocky Linux మరియు AlmaLinux లో default installation నుంచే SELinux enforcing mode ను చూస్తారు. Fedora మరియు RHEL లో కూడా ఇదే ఉంటుంది.