د PAM تصدیق په لاس کار کوي خو د OpenVPN خدمت په توګه ناکامېږي
هغه PAM ننوتل چې د root shell څخه کار کوي او د systemd لاندې ناکامېږي، د پاسورډ پر ځای مرستندوی ته اشاره کوي. امتیازات، د فایل لاسرسی او SELinux بېل کړئ.
د PAM له لارې تصدیق کولی شي بریالی شي کله چې تاسو کلاینټ په لاس چلوئ، او د AUTH_FAILED سره ناکام شي کله چې systemd هماغه پروفایل پیل کړي. پاسورډ د دې چلولو ترمنځ نه بدلېږي؛ هغه څه چې بدلېږي د هغه پروسې شاوخوا د بندیزونو ټولګه ده چې PAM ته پوښتنه کوي. PAM د یوه مرستندوی له لارې ځواب ورکوي چې د خپلو اسنادو د بدلولو وړتیا یې په دقیق ډول هغه څه ده چې یو کلک شوی unit یې لرې کوي. هغه مرستندوی او هغه پوله چې ورته اړتیا لري ومومئ، مخکې له دې چې د وړتیاوو لیست ته لاس ووهئ.
unix_chkpwd هغه باینري ده چې د PAM پوښتنې ځواب ورکوي
د سیمه ییز پاسورډ تصدیق سره، pam_unix ډېر لږ پخپله د هش فایل لولي. دا unix_chkpwd چلوي، چې وېشونه یې setuid root یا setgid shadow ته نصبوي ترڅو یو پاسورډ د هغې پروسې په نوم وڅېړل شي چې /etc/shadow لوستلو ته نه ده مستحقه. د هغې هویت ترلاسه کولو وړتیا لرې کړئ، مرستندوی څېړنه بشپړولی نه شي، نو ماډول یو عادي د تصدیق ناکامي بیرته راګرځوي.
بیا ناکامي په هر هغه لاګ کې چې کلاینټ یې ویني د اسنادو ستونزه ښکاري. دا هماغه ډار دی: کلاینټ هغه څه رپوټ کوي چې PAM ورته ویلي، او PAM یوازې دا رپوټ کوي چې سټیک نه وویل. مرستندوی د root په توګه په لاس چلول هم هېڅ نه ثابتوي، ځکه چې هغه د امتیاز لاره کاروي چې خدمت یې هېڅکله نه کاروي. هغه unit ولولئ چې systemd واقعاً بار کړی، بیا د شوې هڅې لپاره د سیستم لاګ ولولئ. هغه دوه لیدلوري د سانډباک ستونزه له غلط پاسورډ ستونزې څخه بېلوي.
د پاسورډ لاګ له لوستلو مخکې 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 لا هم ورته خدمت کوي.