لینکس میں اجازتیں اس سوال کا جواب دیتی ہیں کہ «یہ فائل کون پڑھ سکتا ہے»۔ AppArmor ایک اور سوال کا جواب دیتا ہے: «اس پروگرام کو سرے سے کرنے کی اجازت کیا ہے»۔ اور فرق نقب زنی کے وقت ظاہر ہوتا ہے۔ web shell ویب سرور کے صارف کے تحت چلتا ہے اور اس کے تمام حقوق ورثے میں لیتا ہے — یعنی نظام کے آدھے حصے تک پڑھنے کی رسائی۔ AppArmor کا پروفائل عمل کو اُسی فہرست تک محدود کرتا ہے جو اسے کام کے لیے چاہیے، اور /etc/shadow پڑھنے یا /bin/bash چلانے کی کوشش صارف کی اجازتوں سے قطع نظر انکار پر ختم ہوتی ہے۔

کیا پہلے سے فعال ہے

sudo aa-status

نتیجہ تین سوالوں کا جواب دیتا ہے: کتنے پروفائل لوڈ ہیں، ان میں سے کتنے enforce اور کتنے complain میں ہیں، اور کون سے عمل بغیر کسی پروفائل کے چل رہے ہیں۔ ایک عام Ubuntu پر چند درجن پروفائل ہوں گے، مگر تقریباً سب man اور tcpdump جیسے معاون پروگراموں کے لیے۔ اور کلیدی سروسز — nginx، Apache، PHP-FPM — عموماً محدود کی فہرست میں نہیں ہوتیں۔

تین وضعیں الگ پہچاننے کے قابل ہیں:

  • enforce — قواعد نافذ ہوتے ہیں، فاضل ہر چیز مسترد؛
  • complain — خلاف ورزیاں صرف جرنل میں درج ہوتی ہیں، کچھ روکا نہیں جاتا۔ ترتیب کی وضع؛
  • unconfined — کوئی پروفائل نہیں، پروگرام بغیر پابندی چلتا ہے۔

اور aa-status کے نتیجے کا سب سے مفید حصہ آخری ہے: وہ عمل جو نیٹ ورک سن رہے ہیں اور کسی چیز سے محدود نہیں۔ اسی فہرست سے آغاز کیا جاتا ہے۔

اوزار

sudo apt install apparmor-utils

اس پیکج کے بغیر aa-complain، aa-enforce اور aa-logprof کمانڈیں نظام میں نہیں ہوتیں، حالانکہ خود AppArmor چل رہا ہوتا ہے۔

سروس روکے بغیر پروفائل کیسے فعال کریں

یہاں ترتیب بنیادی ہے۔ سیدھا enforce میں ڈالا گیا پروفائل بڑی حد تک ممکن ہے کہ سروس کو کوئی ضروری چیز منع کر دے، اور وہ کام کرنا چھوڑ دے — عموماً فوراً نہیں بلکہ کسی نادر عمل پر جیسے فائل کا اپ لوڈ یا میل بھیجنا۔

درست ترتیب:

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

اس وضع میں ایک ہفتے کا کام، ہر غیر معمولی منظرنامے کو سمیٹتے ہوئے: بیک اپ لینا، ایک تازہ کاری، بڑی فائلوں کا اپ لوڈ۔ پھر جو جمع ہوا اس پر نظر ڈالیں:

sudo aa-logprof

یہ کمانڈ درج شدہ خلاف ورزیوں سے گزرتی ہے اور ہر ایک کے بارے میں پوچھتی ہے کہ اجازت دی جائے یا نہیں۔ یہاں توجہ درکار ہے: وہی اجازت دیں جو واقعی سروس کے کام سے تعلق رکھتا ہو، نہ کہ جو بھی سامنے آئے — ورنہ ایسا پروفائل نکلے گا جو سب کچھ جائز کر دے اور سارا مقصد ختم ہو جائے۔

اور تب جا کر:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

انکار کہاں نظر آتے ہیں

تمام خلاف ورزیاں کرنل کے جرنل میں پہنچتی ہیں:

sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log

دوسری فائل تب موجود ہوتی ہے جب auditd نصب ہو — اور اس کے ساتھ اندراجات نمایاں طور پر زیادہ تفصیلی ہوتے ہیں۔ انکار کا اندراج پروفائل کا نام، درخواست کیا گیا عمل اور وہ راستہ دکھاتا ہے جس تک رسائی چاہی گئی؛ اور یہ اتنا کافی ہے کہ طے کر سکیں کہ پروفائل درست کرنا ہے یا خوش ہونا ہے کہ وہ چل گیا۔

اور ایک علامت یاد رکھنے کے قابل ہے: سروس عجیب برتاؤ کرتی ہے — ترتیبات نہیں پڑھتی، ڈائریکٹری میں نہیں لکھتی، ساکٹ نہیں کھولتی — جبکہ اس کے اپنے لاگ میں «permission denied» کی خرابی ایسی اجازتوں کے ساتھ نظر آتی ہے جو بظاہر بالکل درست ہیں۔ یہ تقریباً ہمیشہ AppArmor ہوتا ہے، اور پہلا کام کرنل کے جرنل میں جھانکنا ہے۔

عملی تدبیر، نظری نہیں

PHP-FPM یا nginx کا پروفائل ایک مخصوص انداز میں فائدہ دیتا ہے۔ عمل محدود ہو تو سائٹ تک پہنچنے والا web shell نہ نظامی فائلیں پڑھ سکتا ہے، نہ شیل چلا سکتا ہے، نہ اجازت شدہ ڈائریکٹریوں سے باہر کچھ لکھ سکتا ہے۔ ہیک شدہ سائٹ پوری مشین تک رسائی میں بدلنے کے بجائے ہیک شدہ سائٹ ہی رہتی ہے — اور عین یہی منتقلی نقصان کا بڑا حصہ بناتی ہے۔

اپنانے کی معقول ترتیب: پہلے اُس کے لیے پروفائل جو انٹرنیٹ کی طرف دیکھتا ہے (ویب سرور، PHP-FPM)، پھر ڈیٹابیسوں کے لیے، پھر ضرورت کے مطابق۔ سب کچھ ایک ساتھ فعال کرنے کی ضرورت نہیں، اور کوئی عالمگیر تیار مجموعہ ہے بھی نہیں: پروفائل اس پر منحصر ہے کہ آپ کی فائلیں کہاں ہیں۔

باقاعدگی سے کیا جانچیں

پروفائل آپ کے اندازے سے زیادہ بار unconfined میں لوٹ آتے ہیں: پیکج کی تازہ کاری پروفائل فائل بدل سکتی ہے، ہاتھ سے خرابی دور کرنا سروس کو complain میں چھوڑ دیتا ہے، اور نئی سروس سرے سے بغیر پروفائل کے آتی ہے۔ دو اعداد مفید ہیں: کتنے پروفائل enforce میں ہیں، اور نیٹ ورک کی طرف رخ کیے ہوئے کتنے عمل unconfined میں ہیں۔ اور ان میں سے کسی ایک کی تبدیلی جاننے کے قابل ہے۔ یہ ایک صفحے پر یکجا ہو کر کیسا لگتا ہے، نیچے ڈیمو دکھاتا ہے۔