ٹرمینل میں روٹ، SELinux کے تحت مسترد: hook کیوں ناکام ہوتا ہے

آپ up اسکرپٹ کو روٹ کے طور پر چلاتے ہیں، وہ مکمل ہوتا ہے، اور سروس کے بلانے پر وہی اسکرپٹ ناکام ہو جاتا ہے۔ فائل کی اجازتوں میں کچھ نہیں بدلا، اس لیے اگلا فطری قدم انہیں دوبارہ ڈھیلا کرنا ہے، جو کچھ بھی ٹھیک نہیں کرتا۔ SELinux ہوسٹ پر فیصلہ کن عنصر اکثر یہ نہیں ہوتا کہ عمل کون ہے، بلکہ یہ ہوتا ہے کہ وہ کس ڈومین میں چلتا ہے، اور محدود ڈومین کے اندر روٹ بھی محدود ہی رہتا ہے۔

وہی حکم، دو مختلف سکیورٹی ڈومین

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

اسی لیے دونوں رنز کا موازنہ صرف اسی صورت میں مفید ہے جب آپ ان کے سیاق و سباق کا موازنہ کریں۔ وہی حکم شیل اور hook دونوں سے چلائیں؛ شیل والا نسخہ ثابت کرتا ہے کہ بائنری موجود ہے اور دلائل درست ہیں، لیکن اس بارے میں کچھ ثابت نہیں کرتا کہ سروس کو اسے چلانے کی اجازت ہے یا نہیں۔ دونوں طریقوں سے چلائیں اور صرف ایگزٹ کوڈ نہیں، ڈومین کا موازنہ کریں۔ یہی موازنہ ایک مبہم اجازت کی شکایت کو ایک ڈومین اور ایک لیبل کے بارے میں ٹھوس سوال میں بدل دیتا ہے۔

اس خرابی کی روایتی شکل ایک معاون ہے جو بیرونی ٹول کو بلاتا ہے۔ hook خود اجازت یافتہ ہو سکتا ہے، جبکہ وہ ٹول جسے یہ بلاتا ہے اس پر ایسا لیبل ہوتا ہے جسے سروس کا ڈومین نہیں چلا سکتا، یا ایسی ڈائریکٹری میں لکھتا ہے جس کا لیبل اسے منع کرتا ہے۔

hook کی خرابی کے ساتھ AVC ریکارڈ پڑھیں

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

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

ماخذ سیاق کو اس ڈومین سے مطابقت رکھنی چاہیے جس میں سروس واقعی چلتی ہے، اور ہدف سیاق کو اس فائل یا ڈائریکٹری کے لیبل سے جسے عمل نے چھوا۔ اگر ان میں سے کوئی ایک بھی اس خرابی سے مطابقت نہ رکھے جس کا آپ پیچھا کر رہے ہیں، تو آپ کوئی اور واقعہ پڑھ رہے ہیں۔

ریکارڈ کے ساتھ پالیسی کا ورژن اور قابل عمل فائل کا درست راستہ نوٹ کریں۔ کسی ایک ڈسٹری بیوشن کی پالیسی میں نظر آنے والا ڈومین نام اس انسٹالیشن کے بارے میں ثبوت ہے، یہ ضمانت نہیں کہ کوئی دوسرا بلڈ وہی قواعد فراہم کرتا ہے۔ یہی سیاق دوسرے کو یہ موقع دیتا ہے کہ وہ آپ کا نتیجہ اپنے ہوسٹ پر دہرا سکے۔ اس کے بغیر ریکارڈ ثبوت کی بجائے قصے کی طرح پڑھا جاتا ہے۔

لیبل، کنفیگریشن یا پالیسی: تین مرمتیں

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

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

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

پرانے allow ماڈیول کا جواب کیوں نہیں

اس خرابی کے تلاش کے نتائج تیار ماڈیولز سے بھرے ہیں، اکثر ایسے ٹول کے لیے جسے hook اب نہیں بلاتا۔ ایک انسٹال کرنے سے ایسی اجازتیں ملتی ہیں جن کا آپ کے مسترد ہونے سے کوئی تعلق نہ ہو، اور یہ مستقل سوراخ جوڑتے ہوئے اصل عدم مطابقت کو اس کی جگہ پر رہنے دیتا ہے۔

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

منضبط موازنہ آپ کے پڑھے جا سکنے والے مسترد ہونے اور آپ کی تجویز کردہ تبدیلی کے درمیان ہے۔ Red Hat کی SELinux مسائل کے حل کی گائیڈ لیبلنگ اور کنفیگریشن کی جانچ کو پیدا شدہ پالیسی سے پہلے رکھتی ہے، بالکل اسی وجہ سے۔ اگر ریکارڈ میں کوئی مطابق مسترد نہیں ہے، تو SELinux غالباً آپ کا مسئلہ نہیں، اور راستے، سینڈ باکس یا اجازت کے مسائل اب بھی کھلے ہیں۔