ولې د 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 مه بندوئ۔ دواړه لنډې لارې هغه نظام چې کار کوي ښکاري او هغه امنیتي دریځ چې هیچا نه شي تشریح کولای، ورکوي۔ لنډه څېړنه له دواړو ښه ده۔