PAM تصدیق ہاتھ سے کام کرتی ہے مگر OpenVPN سروس کے طور پر ناکام ہوتی ہے
root شیل سے چلنے والا اور systemd کے تحت ناکام ہونے والا PAM لاگ اِن پاس ورڈ کی نہیں، مددگار کی طرف اشارہ کرتا ہے۔ مراعات، فائل رسائی اور SELinux کو الگ کریں۔
PAM کے ذریعے تصدیق اُس وقت کامیاب ہو سکتی ہے جب آپ کلائنٹ کو ہاتھ سے چلائیں، اور AUTH_FAILED کے ساتھ ناکام ہو سکتی ہے جیسے ہی systemd وہی پروفائل شروع کرتا ہے۔ اِن رنز کے درمیان پاس ورڈ تبدیل نہیں ہوتا؛ جو تبدیل ہوتا ہے وہ اُس عمل کے گرد پابندیوں کا مجموعہ ہے جو PAM سے سوال پوچھتا ہے۔ PAM ایک مددگار کے ذریعے جواب دیتی ہے جس کی اپنے اسناد بدلنے کی صلاحیت عین وہی چیز ہے جو سخت کی گئی unit ہٹا دیتی ہے۔ کوئی بھی صلاحیتوں کی فہرست کو چھونے سے پہلے اُس مددگار اور اُس کی مطلوبہ حد کو تلاش کریں۔
unix_chkpwd وہ بائنری ہے جو PAM کے سوال کا جواب دیتی ہے
مقامی پاس ورڈ تصدیق کے ساتھ، pam_unix خود ہیش فائل کم ہی پڑھتی ہے۔ یہ unix_chkpwd چلاتی ہے، جسے تقسیمیں setuid root یا setgid shadow کے طور پر نصب کرتی ہیں تاکہ ایک پاس ورڈ اُس عمل کی طرف سے جانچا جا سکے جسے /etc/shadow پڑھنے کا کوئی حق نہیں۔ اُس شناخت کو حاصل کرنے کی صلاحیت ہٹا دیں، مددگار جانچ مکمل نہیں کر سکتا، لہٰذا ماڈیول ایک عام تصدیقی ناکامی واپس کرتا ہے۔
پھر ناکامی کلائنٹ کو نظر آنے والے ہر لاگ میں اسناد کے مسئلے کی طرح دکھائی دیتی ہے۔ یہی جال ہے: کلائنٹ وہ بتاتا ہے جو PAM نے اُسے کہا، اور PAM صرف یہ بتاتی ہے کہ اسٹیک نے نہیں کہا۔ مددگار کو root کے طور پر ہاتھ سے چلانا بھی کچھ ثابت نہیں کرتا، کیونکہ یہ اُس مراعاتی راستے کو استعمال کرتا ہے جو سروس کبھی استعمال نہیں کرتی۔ systemd نے جو unit واقعی لوڈ کی وہ پڑھیں، پھر کی گئی کوشش کے لیے سسٹم لاگ پڑھیں۔ یہ دو نقطۂ نظر سینڈ باکس کے مسئلے کو غلط پاس ورڈ کے مسئلے سے الگ کرتے ہیں۔
پاس ورڈ لاگ پڑھنے سے پہلے unit پڑھیں
پیک شدہ unit کوئی ایسا drop-in رکھ سکتی ہے جو آپ نے نہیں لکھا، اور مؤثر ترتیب ضم شدہ نتیجہ ہوتی ہے۔ unit کو اُسی طرح چھاپیں جیسے systemd اُسے دیکھتا ہے، ساتھ ہی اُن سینڈ باکس ترتیبات کے جو طے کرتی ہیں کہ مددگار خود کو بلند کر سکتا ہے یا نہیں۔ اِس مرحلے میں صرف پڑھنے والا معائنہ کافی ہے۔
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -bپہلا حکم بتاتا ہے کہ unit اور اُس کے drop-in کہاں سے آتے ہیں، جو اہم ہے کیونکہ مہینوں پہلے شامل کیا گیا اوور رائیڈ اپنے وجود کی وجہ کی یاد سے زیادہ زندہ رہتا ہے۔ دوسرا وہ سینڈ باکس اقدار چھاپتا ہے جن پر اگلے دو حصے منحصر ہیں۔
جو آپ دیکھتے ہیں اُسے اُسی تقسیم اور ورژن کے کام کرنے والے ہوسٹ سے موازنہ کریں۔ User، CapabilityBoundingSet یا NoNewPrivileges میں فرق ٹھوس سراغ ہے؛ بیانیے کے تبصروں میں فرق نہیں۔ کچھ بھی بدلنے سے پہلے اقدار لکھ لیں، کیونکہ بعد میں حرکت کرتے ہدف کے ساتھ موازنہ کچھ ثابت نہیں کرتا۔ اگر سروس بغیر مراعات والے اکاؤنٹ کے طور پر خالی حدی مجموعے کے ساتھ چلتی ہے، تو مددگار کے پاس کام کرنے کو تقریباً کچھ نہیں ہوتا۔
اسناد کی تبدیلی، فائل رسائی اور پالیسی تین حدیں ہیں
اُس سے شروع کریں جو exec کے دوران ہوتا ہے۔ setuid بائنری یا file capabilities والی فائل اسناد کی تبدیلی کو متحرک کرتی ہے، لہٰذا نتیجے میں ملنے والی شناخت پکارنے والے کا تسلسل نہیں ہوتی۔ حدی مجموعہ محدود کرتا ہے کہ ایسی بائنری کیا حاصل کر سکتی ہے، اور NoNewPrivileges setuid، setgid اور file capabilities کے حصول کو مکمل طور پر روک دیتا ہے۔ اِن تینوں میں سے کوئی بھی مددگار کو روک سکتا ہے جبکہ سروس کا ہر دوسرا کام محفوظ رہتا ہے۔
پھر وسیع صوابدیدی بائی پاس کو تنگ پڑھنے کی رسائی سے الگ کریں۔ CAP_DAC_OVERRIDE تقریباً ہر جگہ صوابدیدی جانچیں چھوڑ دیتا ہے، جبکہ CAP_DAC_READ_SEARCH اپنے اضافی اختیارات کے ساتھ پڑھنے اور ڈائریکٹری گزر کو محیط ہے۔ یہ مختلف اثر دائرے والے مختلف اوزار ہیں، اور اِن میں سے کوئی بھی PAM کو shadow فائل پڑھنے دو لکھنے کا طریقہ نہیں۔
آخر میں پوچھیں کہ کیا لازمی پالیسی اِس عمل کی اجازت دیتی ہے۔ Linux کی صلاحیت SELinux کو اوور رائیڈ نہیں کرتی، اور اُس کا ہونا کسی قسم کے نفاذ کے قاعدے کے بارے میں کچھ ثابت نہیں کرتا۔ فائل رسائی سے انکار اور صلاحیت سے انکار کو مختلف شہادتیں سمجھیں، کیونکہ وہ مختلف اصلاحات اور اکثر مختلف ذمہ دار افراد بتاتے ہیں۔ صرف denied لفظ کی بجائے ریکارڈ کا ہر میدان پڑھیں۔ کس ایگزیکیوٹیبل نے عمل کیا، وہ کس ڈومین میں چلا، کس قسم کے ہدف کو چھوا، کس طبقے کی شے شامل تھی اور پالیسی نے کون سی اجازت رد کی - اِن میں سے ہر ایک جواب کو الگ انداز میں تنگ کرتا ہے۔
انکار کو آڈٹ لاگ سے نکالیں
enforcing حالت والے ہوسٹ پر، آڈٹ ٹریل ہی واحد جگہ ہے جو انکار درج کرتی ہے۔ حالیہ واقعات پوچھیں اور اُنہیں ناکام لاگ اِن کے وقت کی مُہر کے مطابق پڑھیں، نہ کہ اُس وقت کے مطابق جب آپ نے تحقیقات شروع کیں۔
ausearch -m AVC,USER_AVC -ts recentخالی نتیجہ بے گناہی کی شہادت نہیں۔ اِس کا مطلب یا تو یہ ہے کہ آڈٹ جمع نہیں کر رہا، یا یہ کہ آپ کی کھڑکی نے کوشش کھو دی، اور پالیسی کو خارج کرنے سے پہلے دونوں امکانات خارج کرنے ہوں گے۔
Red Hat کی SELinux مسئلہ حل کرنے کی رہنمائی لیبل اور ترتیب کی جانچوں کو اجازت کے قواعد بنانے سے پہلے رکھتی ہے، جو اِس مسئلے کے لیے بھی درست ترتیب ہے۔ غلط لیبل والی مددگار بائنری اور پالیسی میں خلا ملتے جلتے انکار پیدا کرتے ہیں مگر مختلف اصلاح چاہتے ہیں۔ لیبل کی غلطی کے لیے اجازت کا قاعدہ بنانا نقص چھپا دیتا ہے اور اگلی پیکج اپ ڈیٹ کو اُسے دوبارہ لانے دیتا ہے۔ کوئی بھی پالیسی لکھنے سے پہلے نصب شدہ مددگار پر لیبل کی تصدیق کریں۔
ایک قبول شدہ اور ایک مسترد شدہ لاگ اِن سے تبدیلی ثابت کریں
صرف وہی حد بدلیں جو آپ نے ثابت کی، پھر دونوں نتائج جانچیں۔ جس اکاؤنٹ کو تصدیق کرنی چاہیے اُسے کامیاب ہونا چاہیے، اور غلط پاس ورڈ والے اکاؤنٹ کو اب بھی ناکام ہونا چاہیے۔ جو تبدیلی ہر کوشش کو کامیاب کر دے اُس نے تصدیق کو ٹھیک کرنے کی بجائے ہٹا دیا ہے۔
ایک حقیقی کنکشن کی کوشش کریں اور فوراً بعد journal پڑھیں۔ اصلاح ثابت کرنے والی سطر اُس کوشش کے لیے pam_unix(openvpn:auth) اندراج ہے: اُس میں تصدیق کی کامیابی لکھی ہونی چاہیے، اور کوئی AVC ریکارڈ وہی سیکنڈ نہیں رکھنا چاہیے۔
journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpnکام کرنے والی ٹنل کو دوبارہ جڑنے کی بھی ضرورت ہوتی ہے، کیونکہ سینڈ باکس کی تبدیلیاں دوسرے کنکشن کو پہلے سے زیادہ بار توڑتی ہیں۔ دوبارہ جڑنے کے بعد قائم شدہ ساکٹ جانچیں اور تصدیق کریں کہ وہی unit اب بھی اُس کی خدمت کر رہی ہے۔