په 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 څه نه کوي. دا د لارې پوله ده، نه sandbox: هغه پروسه چې امتیاز ساتي کولی شي ترې وتښتي، نو ځکه وړتیا معمولاً له غوښتنې وروسته پرېږدي او نو ځکه محدودیت باید د ډیمون شاوخوا پاتې شي. د AppArmor پروفایل، د وړتیاوو محدودوونکې ټولګه او د فایل سیستم محدودیتونه یوځای ساتل د دې تمرین هدف دی، نه هغه پاتې چې د خدمت له پیل وروسته لرې کېږي.

د پرېکړې قاعده لنډه ده. که د پلټنې ثبت AppArmor ونوموي، نښلول شوي پروفایل ته یوه وړتیا قاعده اضافه کړئ. که اغېزمنه ټولګه تشه وي، د unit چت او د امتیاز پرېښودلو ترتیب سم کړئ. که پروفایل هغه نه وي چې تاسو سم کړی، سمول بند کړئ او ریښتینی ومومئ.