OpenVPN میں chroot ناکام: AppArmor قاعدہ یا صلاحیت؟

ڈیمن chroot کی ناکامی درج کرتا ہے اور پروفائل پہلے ہی کشادہ دکھتا ہے، اس لیے پرکشش حل یہ ہے کہ راستے کا قاعدہ وسیع کر کے دوبارہ شروع کریں۔ عام طور پر اس سے کچھ نہیں بدلتا، کیونکہ chroot کسی ایسے استحقاق سے جکڑا ہے جو پروفائل کبھی منتقل نہیں کر سکا۔ یہ طے کرنے کے لیے کہ کون سی تہہ چھیڑنی ہے، تین جانچیں درکار ہیں اور وہ سستی ہیں: عمل کو کیا رکھنے کی اجازت ہے، پالیسی کیا اجازت دیتی ہے، اور لانچر نے کیا ہٹا تھا اس سے پہلے کہ ان دونوں میں سے کوئی اہم ہوتا۔

دو الگ دروازے، اور ان میں سے صرف ایک AppArmor کا ہے

chroot کو اُس صارف نام کی جگہ میں CAP_SYS_CHROOT درکار ہے جس میں عمل چل رہا ہے۔ یہ Linux کا روایتی استحقاق ہے، جسے کرنل کال کے راستوں کے ساتھ کچھ کرنے سے پہلے جانچتا ہے۔ اس کے علاوہ، نافذ کرنے والا AppArmor پروفائل اس صلاحیت سے انکار کر سکتا ہے جبکہ عمل کے پاس موجود ہو، کیونکہ لازمی پالیسی اسناد کے ساتھ ساتھ دیکھی جاتی ہے، اُن کے بدلے نہیں۔ یہ فرق عملی طور پر اہم ہے: دونوں تہیں الگ فائلوں میں ہیں اور عام طور پر الگ لوگ اُن کی دیکھ بھال کرتے ہیں۔

یہ دونوں دروازے ایک ہی errno کے ساتھ ناکام ہوتے ہیں۔ دونوں EPERM پیدا کرتے ہیں اور دونوں ڈیمن لاگ میں اجازت کی عام شکایت بن کر ابھرتے ہیں، یہی وجہ ہے کہ پروفائل کے مندرجات کا اندازہ لگانے میں اتنا وقت ضائع ہوتا ہے۔ راستے کا قاعدہ جو آپ شامل کرنے والے تھے، chroot کامیاب ہونے کے بعد فائل تک رسائی کو کنٹرول کرتا ہے؛ اس بات سے اس کا کوئی تعلق نہیں کہ کارروائی کو بنیادی طور پر اجازت ہے یا نہیں۔

تیسرا دروازہ دونوں سے اوپر ہے۔ اگر سروس مینیجر یا کوئی ریپر عمل کو اس صلاحیت کے بغیر شروع کرے جو اس کے حد مجموعے میں نہ ہو، تو کوئی AppArmor تبدیلی اُسے واپس نہیں لا سکتی، اور پروفائل میں صلاحیتیں شامل کرنا صرف اُس ارادے کا ریکارڈ ہے جسے کرنل پورا نہیں کرے گا۔

پالیسی میں ترمیم سے پہلے استحقاق کی حالت پڑھیں

اُس کنفیگریشن سے نہیں بلکہ چلتے ہوئے عمل سے شروع کریں جسے آپ فعال سمجھتے ہیں۔ حالت کی فائل پانچ صلاحیت ماسک اور no-new-privileges جھنڈا دکھاتی ہے، اور یہ مختلف سوالوں کے جواب دیتے ہیں:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff وہ مجموعہ ہے جو کال کے لیے اہم ہے: CapBnd میں موجود مگر CapEff میں غائب صلاحیت چھت کی اجازت سے ہے اور اُس وقت رکھی نہیں جا رہی۔ CapAmb تب اہم ہے جب بائنری روایتی setuid معنی میں مستحق نہ ہو، کیونکہ محیطی صلاحیتیں ہی وہ طریقہ ہیں جس سے سروس بغیر فائل صلاحیتوں کے exec کے دوران استحقاق برقرار رکھتی ہے۔ CapInh اُن بٹس کو رکھتا ہے جو exec کے دوران وراثت میں مل سکتے ہیں، لیکن صرف تب جب چلائی جانے والی فائل کا وراثتی مجموعہ اجازت دے، اس لیے وہاں کا بٹ بذات خود کچھ نہیں دیتا۔

پھر تصدیق کریں کہ واقعی کون سا پروفائل منسلک ہے۔ عمل کسی ایسے پروفائل نام سے محدود ہو سکتا ہے جس کی آپ توقع نہیں کرتے، خاص طور پر جب ڈسٹری بیوشن اپنی unit اور اپنا پروفائل اکٹھے بھیجے، اور /proc/PID/attr/current پڑھنا یہ ایک ہی سطر میں طے کر دیتا ہے۔ اپنی تبدیل شدہ فائل کا کرنل کے بتائے ہوئے پروفائل سے موازنہ کرنا وجہ درست کرنے اور ایسی فائل میں ترمیم کرنے کے درمیان فرق ہے جسے کوئی لوڈ نہیں کرتا۔

صلاحیت کا قاعدہ صرف تب شامل کریں جب آڈٹ کا سراغ یہی کہے

کرنل اور آڈٹ کے ریکارڈ اُس تہہ کا نام لیتے ہیں جس نے انکار کیا۔ ایسا انکار تلاش کریں جس میں capable کارروائی اور sys_chroot کا نام ہو، ساتھ اُس پروفائل کے جو اُسے پیدا کرتا ہے۔ اگر وہ ریکارڈ موجود ہے تو عمل کے پاس صلاحیت پہلے سے تھی اور AppArmor نے انکار کیا، اور ہدف تبدیلی حقیقی پروفائل کے اندر ایک صلاحیت کا قاعدہ ہے:

capability sys_chroot,

اُسے اصل میں منسلک پروفائل میں ٹکڑے کے طور پر رکھیں، اور غیر متعلق ٹیوٹوریل سے قاعدہ نقل کرنے کے بجائے کلیدی لفظ apparmor.d پروفائل حوالہ سے جانچیں۔ اُسے مشترکہ include میں ڈالنا یہ حق ہر اُس محدود پروگرام کو دے دیتا ہے جو وہ فائل لوڈ کرتا ہے، اور پروفائل کو complain موڈ میں بدلنا اِس مسئلے کو حل کرنے کے بجائے اگلے انکار کو چھپا دیتا ہے۔ پروفائل کا قاعدہ پالیسی کے انکار کو ہٹاتا ہے؛ یہ استحقاق پیدا نہیں کرتا، اس لیے وہ عمل جس کے مؤثر مجموعے میں CAP_SYS_CHROOT کبھی نہ تھا، قاعدہ موجود ہونے کے باوجود ناکام ہی رہے گا۔

اگر آڈٹ ریکارڈ میں AppArmor کا کوئی انکار نظر نہ آئے تو پروفائل میں ترمیم بند کر دیں۔ آپ اسناد کے مسئلے سے نبرد آزما ہیں، اور باقی کام unit میں یا والد عمل میں ہے، پالیسی کی زبان میں نہیں۔

سروس مینیجر اپنی الگ چھت رکھتا ہے

systemd ہر سروس کے لیے صلاحیتوں کا ایک حد مجموعہ مقرر کرتا ہے، اور بطور طے شدہ وہ مجموعہ تنگ ہوتا ہے۔ وہاں سے خارج شدہ کوئی بھی چیز عمل کے لیے دستیاب نہیں، پروفائل کچھ بھی کہے، یہی وجہ ہے کہ سخت کیے گئے unit اُس کارروائی پر ناکام ہو سکتے ہیں جو ڈیمن ہاتھ سے شروع کرنے پر کام کرتی تھی۔ متعلقہ ہدایات unit میں آسانی سے پڑھی جا سکتی ہیں اور آسانی سے نظر انداز ہو جاتی ہیں جب خود ایپلیکیشن ناکامی کی اطلاع دیتا ہے۔ ڈسٹری بیوشن پیکیج کے فراہم کردہ drop-in ایسی چھت کا عام ذریعہ ہیں جسے کسی کو یاد نہیں کہ اُس نے ترتیب دیا تھا۔

چھت اٹھانا اور صلاحیت دینا دو تبدیلیاں ہیں، ایک نہیں۔ حد مجموعے کا اندراج کہتا ہے کہ عمل یہ صلاحیت رکھ سکتا ہے؛ یہ اُسے مؤثر مجموعے میں شامل نہیں کرتا، اور NoNewPrivs بعد کی ترقی کامیاب ہونے سے روک سکتا ہے چاہے باقی سب ہم آہنگ ہو۔ صرف وہی شامل کریں جس کی کارروائی کو ضرورت ہے، باقی سختی برقرار رکھیں، اور ایک کال گزارنے کے لیے تمام صلاحیتیں دینے کی مختصر راہ کی مخالفت کریں۔

یہاں ترتیب بھی اہم ہے۔ پہلے unit کی چھت بدلیں، تصدیق کریں کہ CapEff میں اب وہ بٹ موجود ہے، اور اُس کے بعد ہی فیصلہ کریں کہ AppArmor اب بھی انکار کرتا ہے یا نہیں۔ دونوں تبدیلیاں ایک ساتھ کرنے سے، ناکامی برقرار رہنے پر آپ پھر اندازہ لگاتے رہ جائیں گے۔

انکار ختم ہونے کے بعد خود جیل کو دیکھیں

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

یہ یاد رکھنا بھی مدد دیتا ہے کہ chroot کیا نہیں کرتا۔ یہ راستے کی حد ہے، سینڈ باکس نہیں: جو عمل استحقاق برقرار رکھے وہ اُس سے نکل سکتا ہے، اسی لیے صلاحیت عام طور پر کال کے بعد چھوڑ دی جاتی ہے اور اسی لیے پابندی ڈیمن کے گرد برقرار رہنی چاہیے۔ AppArmor پروفائل، صلاحیتوں کا حد مجموعہ اور فائل سسٹم کی پابندیاں اکٹھے رکھنا ہی اِس مشق کا مقصد ہے، سروس شروع ہونے کے بعد ہٹانے والی باقیات نہیں۔

فیصلے کا قاعدہ مختصر ہے۔ اگر آڈٹ ریکارڈ AppArmor کا نام لے تو منسلک پروفائل میں ایک صلاحیت کا قاعدہ شامل کریں۔ اگر مؤثر مجموعہ خالی ہے تو unit کی چھت اور استحقاق چھوڑنے کی ترتیب درست کریں۔ اگر پروفائل وہ نہیں جس میں آپ نے ترمیم کی، تو ترمیم بند کریں اور اصل والا تلاش کریں۔