SELinux मुळे nginx 403: समस्या कशी शोधावी

योग्य permissions असलेल्या फाइलवर nginx 403 का परत करतो

फाइलचे permission bits योग्य असूनही nginx 403 परत करत असेल, तर जवळजवळ नेहमीच SELinux (security-enhanced Linux) तिचे वाचन नाकारत असतो. सामान्य 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 असल्याचे दर्शवतो. default_t हा policy ला त्या path ची माहिती नसताना मिळणारा प्रकार आहे. Web server च्या नियमांमध्ये त्या प्रकारचे वाचन अनुमत नसते. 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 परत करतो. त्यामुळे प्रथम कोणत्या स्तराने नकार दिला हे शोधणे आवश्यक आहे. setenforce 0 पासून सुरुवात करू नका.

तुम्हाला आवश्यक असलेला मॉडेलचा भाग

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 अनुमत करणे आवश्यक असते. दोन्ही स्तरांनी access अनुमत केला पाहिजे.

पूर्ण context मध्ये colon ने विभक्त केलेली चार fields असतात, जसे system_u:system_r:httpd_t:s0: SELinux user, role, type आणि level. Server वर तुम्ही जवळजवळ नेहमी तिसऱ्या field वर, म्हणजे type वर, काम करता. Live values पाहण्यासाठी दोन commands आहेत:

ps -eZ | grep nginx
id -Z

nginx workers चा context httpd_t ने समाप्त होतो. तुमच्या login shell चा context unconfined_u:unconfined_r:unconfined_t:s0 असा दिसतो, कारण default targeted policy services वर मर्यादा घालते आणि interactive users ना त्यातून वगळते. हे लक्षात ठेवणे महत्त्वाचे आहे, कारण SELinux services least-privilege users अंतर्गत चालवण्याची जागा घेत नाही. एखाद्याने service मध्ये प्रवेश मिळवल्यानंतर ती कोणत्या resources पर्यंत पोहोचू शकते, यावर SELinux मर्यादा घालते.

तीन मोड आणि कोणत्या images मध्ये SELinux आहे

sestatus
getenforce

Enforcing मोड विनंत्या अडवतो आणि त्यांची नोंद करतो. Permissive मोड सर्वकाही अनुमती देतो आणि त्याने काय अडवले असते याची नोंद करतो. Disabled मोड कोणतेही policy लोड करत नाही. सध्याचा मोड पाहण्यासाठी getenforce चालवा. sestatus /etc/selinux/config मधील मोडही दाखवतो. रीबूटनंतर पुन्हा लागू होणारा मोड हाच असतो.

Rocky Linux, AlmaLinux, Fedora आणि RHEL हे targeted policy सह SELinux Enforcing मोडमध्ये पुरवले जातात. हे समान default योगायोगाने नाही. या चारही distributions ची मुळे Rocky Linux आणि AlmaLinux येण्यापूर्वी CentOS पर्यंत पोहोचणाऱ्या समान Red Hat lineage मध्ये आहेत. तुम्ही यापैकी कोणते वापरता याने या पृष्ठावरील बाबींमध्ये फरक पडत नाही. दोन्हीमध्ये समान policy आणि समान tools असतात. त्यामुळे Rocky Linux आणि AlmaLinux यांपैकी निवड ही security defaults पेक्षा compatibility promises आणि जुन्या CPU साठीच्या support वर अवलंबून असते. Ubuntu आणि Debian त्याऐवजी AppArmor पुरवतात. ते वेगळ्या mechanism द्वारे हेच काम करते. शेवटच्या section मध्ये त्याचे वर्णन आहे. त्यामुळे तुमच्या एका server वर एखादे application कोणत्याही अडचणीशिवाय install होऊ शकते, तर दुसऱ्या server वर ते 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 वर ही दोन्ही साधने आधीच स्थापित करा, कारण त्यांची गरज भासते तोपर्यंत काहीतरी आधीच बिघडलेले असते.

SELinux denial audit log मध्ये कसे वाचावे

प्रत्येक नकार 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 हा block केलेला program आहे. scontext हा source context आहे, म्हणजे process ज्या domain मध्ये चालू होता तो domain. tcontext हा target context आहे, म्हणजे process ने ज्याला access करण्याचा प्रयत्न केला त्या वस्तूवरील label. tclass हा object चा प्रकार आहे; येथे तो file आहे. हे एकत्र वाचल्यास अर्थ असा होतो: httpd_t मधील process ने default_t label असलेली file read करण्याचा प्रयत्न केला आणि permissive=0 सांगते की request केवळ log झाली नाही, तर प्रत्यक्षात block झाली.

ausearch काहीही दाखवत नसेल, तर 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 वाचते आणि तिला ओळखता आलेले कारण सांगते: बंद केलेला boolean, policy शी जुळत नसलेला label किंवा कोणताही rule नसणे. sealert संपूर्ण log तपासते आणि प्रत्येक denial साठी सुचवलेला command दाखवते. ही सूचना केवळ मार्गदर्शक म्हणून वापरा. वेगवेगळ्या releases मध्ये wording बदलते आणि sealert कधी कधी custom policy module सुचवते, जरी एका ओळीतील label दुरुस्ती हे योग्य उत्तर असते.

आणखी एक गोष्ट लक्षात ठेवा. Policy मध्ये dontaudit rules असतात. हे harmless मानल्या जाणाऱ्या denials लपवतात. त्यामुळे log रिकामा असतानाही program चुकीच्या पद्धतीने वागू शकतो. एका test पुरत्या कालावधीसाठी त्या denials पुन्हा दाखवा:

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

semanage fcontext आणि restorecon वापरून चुकीचे label असलेला 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 नियोजित 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 किंवा full relabel ते reset करते, कारण policy नुसार त्या path वर अजूनही वेगळे label असणे अपेक्षित असते. dnf-automatic ठराविक वेळापत्रकानुसार security updates लागू करते अशा machine वर हा reset तुम्ही machine समोर बसलेले नसताना, त्याच्या स्वतःच्या वेळापत्रकानुसार होतो. त्यामुळे तुम्ही शेवटचा बदल केल्यानंतर काही तासांनी site बंद पडू शकते. टिकून राहणारी आवृत्ती म्हणजे semanage fcontext. नोंदवलेले rules sudo semanage fcontext -l | grep '^/data' वापरून सूचीबद्ध करा.

Service ने write करायच्या 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 मधून fail होते, तेव्हा याचेच हे कारण असते.

बूलियन वापरून वर्तनाचा प्रकार दुरुस्त करा

काही अपयश 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 उघडण्याची परवानगी default ने नसते. त्यामुळे 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 शेजारी दाखवतो.

हाताने लिहिलेल्या rule ऐवजी boolean उपलब्ध असल्यास तोच वापरा. Booleans distribution policy सोबत येतात. त्यामुळे त्यांचे maintenance आणि documentation केलेले असते आणि पुढील व्यक्तीला ते सहज सापडतात. getsebool -a system वरील सर्व booleans सूचीबद्ध करते.

सेवेला non-standard port वर listen करू द्या

Ports ना labels देखील असतात. nginx ला 8081 वर हलवल्यावर ते सुरू होण्यास नकार देते:

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

httpd_t ला http_port_t असे label असलेले ports bind करता येतात, आणि 8081 त्यापैकी एक नाही. ते जोडा:

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

प्रथम यादी तपासा. 8008 आणि 8443 यांसह अनेक high ports आधीच परवानगी दिलेले आहेत. एखादा port दोनदा जोडल्यास ValueError: Port tcp/8081 already defined error येतो. तो port आधीपासून वेगळ्या type शी संबंधित असल्यास, तो जोडण्याऐवजी semanage port -m -t http_port_t -p tcp 8081 वापरून type बदला.

हलवलेला SSH port कार्यान्वित करण्यासाठीही हाच command वापरला जातो. journalctl -u sshd मधील Bind to port 2222 on 0.0.0.0 failed: Permission denied याचा अर्थ 2222 हा ssh_port_t मध्ये नाही. त्यामुळे daemon restart करण्यापूर्वी आणि तुमचे session बंद करण्यापूर्वी sudo semanage port -a -t ssh_port_t -p tcp 2222 चालवा. Red Hat family image वर VPS वरील SSH hardening साठी generic guide अनुसरताना लोक ही पायरी वगळतात. SELinux हा firewall नाही. त्यामुळे port अजूनही open असणे आवश्यक आहे: येथे sudo firewall-cmd --permanent --add-port=8081/tcp && sudo firewall-cmd --reload, किंवा Debian किंवा Ubuntu image वरील ufw. --permanent हा flag boolean वरील -P प्रमाणेच reboot-संबंधी अडचण निर्माण करू शकतो. एखादा rule कोणत्या interfaces वर लागू होतो हे ठरवणारे zones एकदा Rocky किंवा AlmaLinux VPS साठी firewalld basics मध्ये वाचणे उपयुक्त ठरते.

जेव्हा बदलण्यासाठी boolean किंवा label उपलब्ध नसतो

सामान्य सर्व्हरवर ही परिस्थिती क्वचितच येते आणि याच ठिकाणी लोक नुकसान करतात. audit2allow लॉगमधील denials वरून 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 वाचा. हे सुरक्षित ठेवण्यासाठी दोन सवयी उपयुक्त आहेत. -c वापरून input फक्त ज्या program मध्ये तुम्ही दुरुस्ती करत आहात त्यापुरते filter करा, कारण असंबंधित denials चा पूर्ण आठवडाभराचा log audit2allow मध्ये pipe केल्यास ते सर्व denials एकाच वेळी मंजूर होतात. तसेच, ज्याचे कारण तुम्ही स्पष्ट करू शकत नाही अशा denial वरून तयार केलेले module कधीही install करू नका: httpd_t ला संपूर्ण सिस्टमवरील प्रत्येक file वाचण्याची परवानगी देणारा rule तयार करणे सोपे आहे, पण काही महिन्यांनंतर तो शोधणे कठीण असते. sudo semodule -r nginx_local वापरून module काढा.

निदानासाठी 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 mode मध्ये सेवा पहिल्या denial वर थांबते. त्यामुळे ती समस्या दुरुस्त करून सेवा पुन्हा सुरू केल्यावर दुसरा denial दिसतो. permissive mode मध्ये प्रक्रिया सुरू राहते आणि एकाच वेळी झालेल्या run मध्ये log मध्ये सर्व denials जमा होतात. त्यानंतर enforcing mode पुन्हा सुरू करून त्या सर्व समस्या एकत्र दुरुस्त करता येतात.

setenforce मुळे /etc/selinux/config वर कोणताही परिणाम होत नाही. त्यामुळे reboot केल्यावर मशीन पुन्हा enforcing mode मध्ये येते. हे एक safety net आहे. म्हणून setenforce 0 करून केलेली "दुरुस्ती" सर्वात अयोग्य वेळी पुन्हा दिसू शकते. एखाद्या सेवेवर काम करताना तिला तात्पुरती अधिक मुभा द्यायची असल्यास संपूर्ण मशीनऐवजी त्या domain ला mark करा: sudo semanage permissive -a httpd_t मुळे इतर सर्व domain enforcing mode मध्येच राहतात, आणि sudo semanage permissive -d httpd_t ही स्थिती पूर्ववत करते.

SELinux अक्षम करण्याची किंमत label दुरुस्त करण्यापेक्षा जास्त का असते

/etc/selinux/config मध्ये SELINUX=disabled सेट केल्यास एक ओळीतील label दुरुस्त करण्याऐवजी सर्व्हरची सुरक्षा कायमची कमकुवत होते. Web application compromise झालेल्या दिवशी हा फरक स्पष्ट दिसतो. Enforcing मोडमध्ये हल्लेखोराचा code httpd_t मध्ये चालतो. त्यामुळे तो web content वाचू शकतो; परंतु /etc/shadow वाचणे किंवा systemd unit लिहिणे policy नुसार नाकारले जाते, Unix user ने त्याला परवानगी दिली असती तरीही. कोणतीही policy load केलेली नसल्यास, त्याच code ला service account कडे असलेले सर्व अधिकार मिळतात.

SELinux अक्षम करण्याची आणखी एक किंमत नंतर मोजावी लागते. कोणतीही policy load केलेली नसताना नवीन files कोणत्याही label शिवाय तयार होतात. त्यामुळे filesystem आणि policy यांच्यात विसंगती निर्माण होते. SELinux पुन्हा सुरू केल्यावर पूर्ण relabel करावे लागते. अन्यथा अनेक services एकाच वेळी fail होतात:

sudo fixfiles -F onboot
sudo reboot

यामुळे /.autorelabel लिहिले जाते आणि पुढील boot दरम्यान प्रत्येक filesystem ला relabel केले जाते. मोठ्या disk वर याला बराच वेळ लागतो आणि console अडकलेली असल्यासारखी दिसते. त्यामुळे प्रतीक्षा करता येईल तेव्हा ही प्रक्रिया सुरू करा. मशीन तसेही बंद होणार असल्याने, restart साठी आणखी काय queue मध्ये आहे हे आधी तपासणे उपयुक्त ठरते. dnf update नंतर जुन्या kernels आणि libraries memory मध्ये राहिल्यावर needs-restarting कोणती माहिती दाखवते यासाठी तेच वापरले जाते. Rocky Linux आणि AlmaLinux 9 मध्ये config file आता स्वतःहून kernel भाग बंद करत नाही. SELinux पूर्णपणे अक्षम करण्याची documented पद्धत म्हणजे kernel argument (sudo grubby --update-kernel ALL --args selinux=0) वापरणे. दुसऱ्याचा server ताब्यात घेताना हा command माहीत असणे उपयुक्त ठरते. 403 साठी ही दुरुस्ती नाही.

कंटेनरमध्ये आणखी एक लेबल जोडा

Red Hat कुटुंबातील host वर container processes container_t मध्ये चालतात आणि ते फक्त container_file_t लेबल असलेल्या फाइल्स वाचू शकतात. Host वरील bind mount कंटेनरमध्ये Permission denied मुळे अपयशी ठरतो, जरी host वर ls -l अगदी सामान्य दिसत असले तरी. :Z suffix मुळे runtime mount ला पुन्हा label करतो:

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

:Z ही directory फक्त या container साठी label करते. :z ती containers मध्ये share करण्यासाठी label करते. इतर services वापरत असलेल्या directory कडे :Z निर्देश केल्यास ती directory recursively पुन्हा label केली जाते. त्यामुळे त्या 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 वापरले जाते. त्याऐवजी disk वरील files ला label लावले जात नाहीत. 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 mode) आणि ते पुन्हा पूर्ववत करण्यासाठी aa-enforce वापरा. Ubuntu निवडक packaged services वर निर्बंध लागू करते आणि उर्वरित services unconfined ठेवते. त्यामुळे प्रत्यक्षात काय सक्रिय आहे हे पाहण्यासाठी aa-status वाचा; अंदाजावर अवलंबून राहू नका.

दोन्ही systems मध्ये एकच सवय उपयुक्त ठरते. एखादी service योग्य दिसणाऱ्या गोष्टीवर Permission denied अशी सूचना देत असेल, तर permissions बदलण्यापूर्वी security log वाचा. एकाच समस्येचे कारण पुन्हा पुन्हा permissions असणे क्वचितच घडते.

FAQ

nginx परवानग्या योग्य असतानाही 403 का परत करते?

कारण permission bits मुळे नाही, तर SELinux ने read नाकारले आहे. Web server httpd_t domain मध्ये चालतो आणि तो केवळ web content साठी label केलेल्या फाइल्सच read करू शकतो. त्यामुळे default_t किंवा admin_home_t label असलेली फाइल नाकारली जाते आणि nginx कडे serve करण्यासाठी काहीही उरत नाही. 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 ही निदानाची पायरी आहे; तो उपाय नाही. समस्येची एकदा पुनरावृत्ती करण्यासाठी तो वापरा, जेणेकरून log मध्ये सर्व denials एकाच pass मध्ये नोंदवले जातील. ते sudo ausearch -m AVC -ts recent वापरून वाचा. त्यानंतर sudo setenforce 1 चालवून कारणे दुरुस्त करा. permissive स्थितीत ठेवलेल्या server मध्ये प्रत्येक denial नोंदवला जातो, पण कोणताही denial block केला जात नाही. त्यामुळे अनावश्यक नोंदी वाढतात आणि संरक्षण कमी होते. काम करताना एखाद्या सेवेला तात्पुरती मुभा हवी असल्यास sudo semanage permissive -a httpd_t चालवा, जेणेकरून उर्वरित machine enforcing स्थितीत राहील.

SELinux enforcing असताना 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. आधी 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 मध्ये AppArmor दिलेले असते. ते फाइल्सवरील labels ऐवजी executable च्या path शी जोडलेले profile लागू करते. sudo aa-status वापरून त्याची स्थिती तपासा आणि sudo journalctl -k मध्ये apparmor="DENIED" lines शोधा. Ubuntu निवडक packaged services वर restrictions लागू करते, त्यामुळे अनेक programs default ने unconfined चालतात. Rocky Linux आणि AlmaLinux मध्ये SELinux enforcing default ने आढळते. Fedora आणि RHEL मध्येही तेच लागू आहे.