SELinux کی وجہ سے nginx 403: label کیسے درست کریں

nginx ایسی فائل پر 403 کیوں واپس کرتا ہے جس کی permissions درست ہوں

ایسی فائل پر nginx کا 403 واپس کرنا، جس کے permission bits درست ہوں، تقریباً ہمیشہ 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 موجود ہے۔ default_t وہ label ہے جو کسی path کو اس وقت ملتا ہے جب policy اس path سے پہلے واقف نہ ہو۔ 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"

kernel دونوں طرح کی ممانعت، یعنی عام ممانعت اور SELinux کی ممانعت، کے لیے 13: Permission denied واپس کرتا ہے۔ اس لیے پہلا کام یہ معلوم کرنا ہے کہ انکار کس layer نے کیا۔ 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 کے مجاز امتزاج کی فہرست ہوتی ہے، اور جو چیز اس فہرست میں شامل نہ ہو اسے deny کر دیا جاتا ہے۔ یہ 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 موجودہ values دکھاتی ہیں:

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 میں داخل ہو جائے تو SELinux اس کے بعد service کی رسائی کو محدود رکھتا ہے۔

تین modes اور یہ کہ کن images میں SELinux موجود ہے

sestatus
getenforce

Enforcing رسائی روکتا اور اسے log کرتا ہے۔ Permissive ہر چیز کی اجازت دیتا ہے اور یہ log کرتا ہے کہ وہ کن چیزوں کو روکتا۔ Disabled کوئی policy load نہیں کرتا۔ getenforce موجودہ mode دکھاتا ہے۔ sestatus /etc/selinux/config سے mode بھی دکھاتا ہے، اور reboot کے بعد یہی mode دوبارہ فعال ہوتا ہے۔

Rocky Linux، AlmaLinux، Fedora اور RHEL، targeted policy کے ساتھ SELinux کو Enforcing mode میں فراہم کرتے ہیں۔ Ubuntu اور Debian اس کے بجائے AppArmor فراہم کرتے ہیں، جو مختلف mechanism کے ذریعے یہی کام کرتا ہے۔ آخری section میں اس کا احاطہ کیا گیا ہے۔ اسی لیے ایک ہی application آپ کے کسی server پر درست طور پر install ہو سکتی ہے، جبکہ دوسرے server پر 403 واپس کر سکتی ہے۔

ضرورت پڑنے سے پہلے tools انسٹال کریں

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 میں کیسے پڑھیں

ہر refusal، audit daemon کے ذریعے AVC (access vector cache) message کے طور پر record ہوتی ہے:

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 ہے جسے block کیا گیا۔ scontext source context ہے، یعنی وہ domain جس میں process چل رہا تھا۔ tcontext target context ہے، یعنی اس چیز پر موجود label جس تک process رسائی کی کوشش کر رہا تھا۔ tclass object کی قسم ہے؛ یہاں یہ file ہے۔ انہیں ملا کر مفہوم یہ بنتا ہے: httpd_t میں چلنے والے process نے default_t سے labelled file کو read کرنے کی کوشش کی، اور permissive=0 بتاتا ہے کہ request صرف log نہیں ہوئی بلکہ واقعی block بھی کی گئی۔

اگر ausearch کچھ print نہ کرے تو audit daemon شاید چل نہیں رہا۔ ایسی صورت میں denials 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 کو پڑھتا ہے اور اپنی شناخت کے مطابق وجہ بتاتا ہے: کوئی boolean switched off ہے، کوئی label policy سے match نہیں کرتا، یا کوئی rule موجود ہی نہیں۔ sealert پورے log کو پڑھتا ہے اور ہر denial کے لیے ایک تجویز کردہ command print کرتا ہے۔ اس تجویز کو صرف hint سمجھیں۔ مختلف releases میں اس کی wording بدل سکتی ہے، اور sealert کبھی custom policy module بنانے کی تجویز دیتا ہے، حالانکہ درست حل صرف ایک سطر میں label درست کرنا ہوتا ہے۔

ایک اور بات بھی جانیں۔ Policy میں dontaudit rules شامل ہوتے ہیں جو harmless سمجھی جانے والی denials کو چھپا دیتے ہیں۔ اس لیے log خالی رہنے کے باوجود program غلط طریقے سے کام کر سکتا ہے۔ ایک test کے دورانیے تک انہیں دوبارہ ظاہر کریں:

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 کا مطلب ہے کہ کوئی action نہ لیا جائے۔ حقیقی restorecon کے بعد label httpd_sys_content_t کے طور پر نظر آتا ہے اور service restart کیے بغیر 403 ختم ہو جاتا ہے۔

chcon کو صرف test کے طور پر استعمال کریں۔ chcon -t httpd_sys_content_t index.html label براہِ راست set کرتا ہے، اور اگلا restorecon، package update یا full relabel اسے reset کر دیتا ہے، کیونکہ policy اب بھی کہتی ہے کہ اس path کا label کچھ اور ہونا چاہیے۔ semanage fcontext وہ version ہے جو برقرار رہتا ہے۔ sudo semanage fcontext -l | grep '^/data' سے ریکارڈ کیے گئے labels کی فہرست دیکھیں۔

جس content پر service کو write کرنا ہو، اسے مختلف 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 پیدا ہوتا ہے۔ جب page /usr/share/nginx/html سے درست 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 کھولنے کی اجازت نہیں ہوتی، اس لیے 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 پر تبدیلی ختم ہو جاتی ہے، اور service صرف اسی وقت تک کام کرتی ہے جب تک machine restart نہ ہو۔ semanage boolean -l | grep httpd_can_network_connect سے تصدیق کریں۔ یہ running value کو stored value کے ساتھ دکھاتا ہے۔

جب بھی boolean دستیاب ہو، خود لکھی ہوئی rule کے بجائے اسے ترجیح دیں۔ Booleans distribution policy کے ساتھ جاری ہوتے ہیں، اس لیے ان کی maintenance ہوتی ہے، documentation دستیاب ہوتی ہے، اور اگلے administrator کے لیے انہیں تلاش کرنا آسان ہوتا ہے۔ getsebool -a سسٹم پر موجود تمام booleans کی فہرست دکھاتا ہے۔

سروس کو غیر معیاری port پر listen کرنے دیں

Ports کے لیے labels بھی مقرر ہوتے ہیں۔ nginx کو 8081 پر منتقل کریں، تو یہ start ہونے سے انکار کر دیتا ہے:

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

httpd_t صرف http_port_t سے منسلک ports پر bind کر سکتا ہے، اور 8081 ان میں شامل نہیں ہے۔ اسے شامل کریں:

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

پہلے فہرست دیکھ لیں۔ کئی high ports پہلے ہی allowed ہیں، جن میں 8008 اور 8443 شامل ہیں، اور کسی port کو دوسری بار شامل کرنے سے ValueError: Port tcp/8081 already defined کے ذریعے failure ہوتا ہے۔ اگر port پہلے ہی کسی مختلف type سے وابستہ ہو تو اسے شامل کرنے کے بجائے semanage port -m -t http_port_t -p tcp 8081 سے تبدیل کریں۔

یہی command منتقل کیے گئے SSH port کو بھی کام کرنے کے قابل بناتی ہے۔ 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 کو harden کرنے کے لیے عمومی guide کی پیروی کرتے وقت لوگ یہی مرحلہ چھوڑ دیتے ہیں۔ SELinux firewall بھی نہیں ہے، اس لیے port کو پھر بھی open کرنا ہوگا: یہاں sudo firewall-cmd --permanent --add-port=8081/tcp && sudo firewall-cmd --reload، یا Debian یا Ubuntu image پر ufw استعمال کریں۔

جب تبدیل کرنے کے لیے کوئی 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 تک محدود کریں جسے آپ درست کر رہے ہیں، کیونکہ ایک ہفتے کے غیر متعلقہ denials کو audit2allow میں pipe کرنے سے وہ سب ایک ساتھ grant ہو جاتے ہیں۔ اور جس denial کی وجہ آپ بیان نہ کر سکیں، اس سے بنایا گیا module کبھی install نہ کریں: ایسا rule جو httpd_t کو server کی ہر file پڑھنے کی اجازت دیتا ہو، بنانا آسان ہے لیکن کئی ماہ بعد اس کا سراغ لگانا مشکل ہوتا ہے۔ 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 رسائی کی اجازت دیتا ہے اور اسے log میں درج کرتا ہے۔ اس کی اصل افادیت مکمل معلومات فراہم کرنا ہے۔ enforcing mode میں service پہلی denial پر رک جاتی ہے۔ آپ اسے درست کرتے ہیں، دوبارہ start کرتے ہیں، اور دوسری denial کا سامنا کرتے ہیں۔ permissive mode میں عمل جاری رہتا ہے، اور log ایک ہی run میں تمام denials جمع کر لیتا ہے۔ اس کے بعد آپ دوبارہ enforcing mode فعال کر کے انہیں ایک ساتھ درست کر سکتے ہیں۔

setenforce، /etc/selinux/config کو تبدیل نہیں کرتا۔ اس لیے reboot کے بعد system دوبارہ enforcing mode میں آ جاتا ہے۔ یہ ایک حفاظتی انتظام ہے۔ اسی وجہ سے وہ "حل" جس میں صرف setenforce 0 شامل تھا، انتہائی نامناسب وقت پر دوبارہ ظاہر ہو جاتا ہے۔ اگر کسی ایک service کو کام کے دوران اضافی گنجائش درکار ہو تو پوری machine کے بجائے اس domain کو mark کریں: sudo semanage permissive -a httpd_t باقی تمام domains کو enforcing mode میں رکھتا ہے، جبکہ sudo semanage permissive -d httpd_t اس تبدیلی کو واپس کرتا ہے۔

SELinux کو غیر فعال کرنا label درست کرنے سے زیادہ مہنگا کیوں ہے

SELINUX=disabled کو /etc/selinux/config میں set کرنے سے ایک سطری label درست کرنے کے بدلے سرور مستقل طور پر کم محفوظ ہو جاتا ہے۔ اس فرق کا اثر اس دن ظاہر ہوتا ہے جب web application breach ہو جائے۔ enforcing mode میں حملہ آور کا code httpd_t میں چلتا ہے، اس لیے وہ web content پڑھ سکتا ہے، لیکن policy کی وجہ سے /etc/shadow پڑھنے یا systemd unit لکھنے کی اجازت نہیں ملتی، خواہ Unix user کو اس کی اجازت حاصل ہو۔ اگر کوئی policy load نہ ہو تو یہی code service account کو حاصل تمام اختیارات استعمال کر سکتا ہے۔

اس کے علاوہ، SELinux کو غیر فعال کرنے کی قیمت بعد میں ادا کرنا پڑتی ہے۔ جب کوئی policy load نہ ہو تو نئی files بغیر label کے create ہوتی ہیں، اس لیے filesystem policy سے ہم آہنگ نہیں رہتا۔ SELinux دوبارہ فعال کرنے کے لیے مکمل relabel درکار ہوتا ہے، ورنہ بیک وقت متعدد services fail ہو سکتی ہیں:

sudo fixfiles -F onboot
sudo reboot

اس سے /.autorelabel لکھا جاتا ہے اور اگلے boot کے دوران ہر filesystem کا relabel کیا جاتا ہے۔ بڑی disk پر اس عمل میں کافی وقت لگتا ہے اور console بظاہر رکا ہوا محسوس ہو سکتا ہے، اس لیے اسے اس وقت شروع کریں جب آپ انتظار کر سکیں۔ Rocky Linux اور AlmaLinux 9 میں config file اب خود kernel کے حصے کو غیر فعال نہیں کرتی، اور SELinux کو مکمل طور پر disable کرنے کا 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 سے labelled files پڑھ سکتے ہیں۔ Host سے bind mount کرنے پر container کے اندر Permission denied ناکام ہو جاتا ہے، جبکہ host پر ls -l بالکل درست دکھائی دیتا ہے۔ :Z suffix runtime کو mount کی relabeling کرنے کی ہدایت دیتا ہے:

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

:Z اس directory کو صرف اسی container کے لیے label کرتا ہے۔ :z اسے containers کے درمیان sharing کے لیے label کرتا ہے۔ اگر :Z کو ایسی directory پر لگائیں جسے دوسری services استعمال کرتی ہیں تو یہ اس directory کو recursively relabel کر دے گا، جس سے وہ services متاثر ہوں گی۔ اس لیے containers کے لیے الگ paths بنائیں۔ Setup کی باقی تمام تفصیلات کسی بھی دوسری image جیسی ہیں، جنہیں VPS پر Docker چلانا میں بیان کیا گیا ہے۔

Ubuntu اور Debian آپ کو AppArmor فراہم کرتے ہیں

کام وہی ہے، ڈیزائن مختلف ہے۔ AppArmor کسی پروگرام کو اس کی executable فائل کے path کی بنیاد پر محدود کرتا ہے۔ یہ /etc/apparmor.d/ کے تحت موجود profile استعمال کرتا ہے، بجائے اس کے کہ disk پر موجود files کو label کیا جائے۔ کسی file کو دوبارہ 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 mode ہے، جبکہ aa-enforce اسے دوبارہ فعال کرنے کے لیے استعمال ہوتا ہے۔ Ubuntu packaged services کے ایک منتخب مجموعے کو محدود رکھتا ہے اور باقی services کو unconfined چھوڑ دیتا ہے۔ اس لیے یہ فرض کرنے کے بجائے کہ واقعی کیا فعال ہے، aa-status پڑھیں۔

ایک عادت دونوں systems میں یکساں مفید ہے۔ جب کوئی service کسی ایسی چیز پر Permission denied رپورٹ کرے جو درست دکھائی دیتی ہو، تو permissions تبدیل کرنے سے پہلے security log پڑھیں۔ اکثر مسئلہ file permissions میں نہیں ہوتا۔

FAQ

nginx درست file permissions کے باوجود 403 کیوں واپس کرتا ہے؟

کیونکہ SELinux نے read کی اجازت نہیں دی، permission bits نے نہیں۔ Web server httpd_t domain میں چلتا ہے اور صرف web content کے لیے labelled files پڑھ سکتا ہے، اس لیے default_t یا admin_home_t label والی file مسترد کر دی جاتی ہے اور nginx کے پاس serve کرنے کے لیے کچھ نہیں رہتا۔ sudo ausearch -m AVC -ts recent سے تصدیق کریں؛ یہ scontext کو httpd_t پر ختم ہوتے اور tcontext میں غلط type موجود دکھاتا ہے۔ پھر درست label محفوظ کر کے اسے apply کریں: sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"، اس کے بعد sudo restorecon -Rv /data/www۔

کیا service کو چلانے کے لیے setenforce 0 استعمال کرنا محفوظ ہے؟

setenforce 0 ایک diagnostic قدم ہے، fix نہیں۔ مسئلے کو ایک بار reproduce کرنے کے لیے اسے استعمال کریں تاکہ log ایک ہی pass میں تمام denials جمع کر لے، انہیں sudo ausearch -m AVC -ts recent سے پڑھیں، پھر sudo setenforce 1 چلائیں اور وجوہات درست کریں۔ permissive حالت میں چھوڑا گیا server ہر denial کو log کرتا ہے اور کسی کو block نہیں کرتا، اس لیے noise برقرار رہتا ہے اور protection ختم ہو جاتی ہے۔ اگر کام کے دوران کسی ایک service کو عارضی گنجائش درکار ہو تو sudo semanage permissive -a httpd_t چلائیں تاکہ باقی machine enforcing حالت میں رہے۔

SELinux enforcing حالت میں non-standard port پر service کیسے چلاؤں؟

Port کو اس type میں شامل کریں جس پر وہ service bind کر سکتی ہے۔ 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 سے موجودہ list چیک کریں، کیونکہ پہلے سے listed port کے ساتھ ValueError: Port tcp/8081 already defined fail ہو جاتا ہے۔ اس قدم کے بغیر daemon startup پر bind() ... Permission denied کے ساتھ exit ہو جاتا ہے، حالانکہ کوئی دوسرا process port استعمال نہیں کر رہا ہوتا۔

کیا Ubuntu میں SELinux موجود ہے؟

نہیں۔ Ubuntu اور Debian کے ساتھ AppArmor آتا ہے، جو files پر labels کے بجائے executable کے path سے منسلک profile نافذ کرتا ہے۔ sudo aa-status سے اسے چیک کریں اور sudo journalctl -k میں apparmor="DENIED" lines تلاش کریں۔ Ubuntu منتخب packaged services کو confine کرتا ہے، اس لیے بہت سے programs default طور پر unconfined چلتے ہیں۔ Rocky Linux اور AlmaLinux میں SELinux enforcing حالت میں out of the box ملتا ہے، اسی طرح Fedora اور RHEL میں بھی۔