VPN سرٹیفکیٹ کو منتقل کرنا اس کا SELinux لیبل کیوں توڑ دیتا ہے

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

نام بدلنا لیبل کے ساتھ درحقیقت کیا کرتا ہے

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

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

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

موجودہ لیبل کو متوقع لیبل کے سامنے پڑھیں

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

پھر فرق کو حقیقی انکار سے جوڑیں۔ عدم مطابقت غلط لیبل کا ثبوت ہے، یہ ثبوت نہیں کہ سروس اس کی وجہ سے ناکام ہوئی، اور لاگ میں متعلقہ انکار کے بغیر لگایا گیا اصلاح اضافی قدموں والا اندازہ ہے۔

استثنا ایجاد کرنے کے بجائے میپنگ بحال کریں

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

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

chcon ہی حل کیوں نہیں ہے

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

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

جب لیبل درست ہو اور رسائی پھر بھی ناکام ہو

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

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

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