د تمديد؛ DR. پدې مقاله کې ، موږ د سخت کولو سکیمونه وپلټئ چې د لینکس پنځه مشهور توزیعونو کې د بکس څخه بهر کار کوي. د هر یو لپاره، موږ د ډیفالټ کرنل ترتیب واخیست، ټولې کڅوړې یې ډکې کړې، او په ضمیمه بائنریونو کې د امنیت سکیمونه تحلیل کړل. هغه توزیع چې په پام کې نیول شوي د OpenSUSE 12.4، Debian 9، CentOS، RHEL 6.10 او 7، او همدارنګه اوبنټو 14.04، 12.04 او 18.04 LTS دي.

پایلې تاییدوي چې حتی لومړني سکیمونه لکه د کانریونو سټیک کول او د موقعیت خپلواک کوډ لاهم د هرچا لخوا ندي منل شوي. وضعیت د تالیف کونکو لپاره خورا خراب دی کله چې د زیانونو په وړاندې د ساتنې خبره راځي لکه د سټیک کلاش ، کوم چې د جنوري په میاشت کې د خپریدو وروسته په پام کې نیول شوی. د سیسټم شوي زیانونو په اړه معلومات. مګر هرڅه دومره نا امید نه دي. د بائنریونو یو د پام وړ شمیر د محافظت لومړني میتودونه پلي کوي ، او د دوی شمیر له نسخې څخه نسخې ته وده کوي.

بیاکتنې ښودلې چې د محافظت میتودونو ترټولو لوی شمیر په اوبنټو 18.04 کې د OS او غوښتنلیک په کچه پلي کیږي ، ورپسې Debian 9. له بلې خوا ، OpenSUSE 12.4 ، CentOS 7 او RHEL 7 هم د لومړني محافظت سکیمونه پلي کوي ، او د ټکر محافظت سټک کوي. د ډیفالټ کڅوړو د خورا سخت سیټ سره حتی په پراخه کچه کارول کیږي.

پېژندنه

د لوړ کیفیت سافټویر ډاډ ترلاسه کول ستونزمن دي. د جامد کوډ تحلیل او متحرک چلولو تحلیل لپاره د ډیری پرمختللو وسیلو سره سره ، په بیله بیا د تالیف کونکو او برنامه کولو ژبو په پراختیا کې د پام وړ پرمختګ سره ، عصري سافټویر لاهم د زیانونو سره مخ دي چې په دوامداره توګه د برید کونکو لخوا کارول کیږي. وضعیت په ایکوسیستمونو کې حتی خراب دی چې د میراث کوډ پکې شامل دي. په داسې قضیو کې، موږ نه یوازې د احتمالي استخراجي غلطیو موندلو له ابدي ستونزې سره مخ یو، بلکې موږ د سخت شاته مطابقت چوکاټونو لخوا هم محدود یو، چې ډیری وختونه موږ د محدود، یا حتی بدتر، زیانمنونکي یا بګی کوډ ساتلو ته اړتیا لرو.

دا هغه ځای دی چې د پروګرامونو د ساتنې یا سختولو طریقې په عمل کې راځي. موږ نشو کولی د ځینو ډولونو غلطیو مخه ونیسو، مګر موږ کولی شو د برید کونکي ژوند ډیر ستونزمن کړو او د مخنیوي یا مخنیوي له لارې ستونزه تر یوې اندازې حل کړو. استحصال دا تېروتنې. دا ډول محافظت په ټولو عصري عملیاتي سیسټمونو کې کارول کیږي، مګر میتودونه په پیچلتیا، موثریت او فعالیت کې خورا توپیر لري: د سټیک کانریز او ASLR د بشپړ محافظت لپاره CFI и رپ. پدې مقاله کې ، موږ به وګورو چې په ډیفالټ ترتیب کې د لینکس خورا مشهور توزیع کې د محافظت کومې میتودونه کارول کیږي ، او د بائنری ملکیتونه هم وڅیړو چې د هر توزیع بسته مدیریت سیسټمونو له لارې توزیع شوي.

CVE او امنیت

موږ ټولو د سرلیکونو سره مقالې لیدلي دي لکه "د کال ترټولو زیان منونکي غوښتنلیکونه" یا "ډیری زیان منونکي عملیاتي سیسټمونه." معمولا دوی د زیان منونکو په اړه د ریکارډونو ټولټال شمیرې احصایې چمتو کوي لکه CVE (عام زیانمنتیا او افشا کول)، څخه ترلاسه شوی ملي زیانمنتیا ډیټابیس (NVD) от نیست او نورې سرچینې. وروسته، دا غوښتنلیکونه یا OS د CVEs شمیر لخوا درجه بندي کیږي. له بده مرغه، پداسې حال کې چې CVEs د مسلو تعقیب او د پلورونکو او کاروونکو خبرولو لپاره خورا ګټور دي، دوی د سافټویر اصلي امنیت په اړه لږ څه وايي.

د مثال په توګه، د لینکس کرنل لپاره په تیرو څلورو کلونو کې د CVEs ټولټال شمیر او پنځه خورا مشهور سرور توزیعونه په پام کې ونیسئ، د بیلګې په توګه اوبنټو، دیبیان، ریډ هټ انټرپریس لینکس او OpenSUSE.

عکس ایکس اینمکس

دا ګراف موږ ته څه وایی؟ ایا د CVEs لوړه شمیره پدې معنی ده چې یو ویش د بل په پرتله ډیر زیان منونکی دی؟ هیڅ ځواب نشته. د مثال په توګه ، پدې مقاله کې به تاسو وګورئ چې دیبیان د OpenSUSE یا RedHat لینکس په پرتله قوي امنیت میکانیزمونه لري ، او لاهم دیبیان ډیر CVEs لري. په هرصورت، دا د ضعیف امنیت معنی نلري: حتی د CVE شتون دا نه په ګوته کوي چې ایا زیان منونکی دی. استحصال شوی. د شدت نمرې د دې ښودنه کوي چې څنګه شاید د زیانمننې استخراج، مګر بالاخره استثمار په اغیزمنه سیسټمونو کې موجود محافظت او د برید کونکو سرچینو او وړتیاوو پورې اړه لري. سربیره پردې، د CVE راپورونو نشتوالی د نورو په اړه څه نه وايي غیر راجستر شوی یا نامعلوم زیانمنتیاوې په CVE کې توپیر ممکن د سافټویر کیفیت پرته د نورو فکتورونو له امله وي ، پشمول د ازموینې لپاره تخصیص شوي سرچینې یا د کارونکي اساس اندازه. زموږ په مثال کې، د دیبیان د CVEs لوړه شمیره ممکن په ساده ډول په ګوته کړي چې دبیان ډیر سافټویر کڅوړې لیږدوي.

البته، د CVE سیسټم ګټور معلومات چمتو کوي چې تاسو ته اجازه درکوي مناسب محافظتونه رامینځته کړئ. څومره چې موږ د پروګرام د ناکامۍ په لاملونو ښه پوهیږو، هغومره د استخراج د ممکنه میتودونو پیژندل او د مناسب میکانیزمونو رامینځته کول اسانه دي. کشف او غبرګون. په انځور کې. 2 په تیرو څلورو کلونو کې د ټولو ویشونو لپاره د زیان منونکو کټګورۍ ښیې (سرچینه). دا سمدلاسه روښانه ده چې ډیری CVEs په لاندې کټګوریو کې راځي: د خدماتو څخه انکار (DoS) ، د کوډ اجرا کول ، ډیر جریان ، د حافظې فساد ، د معلوماتو افشا کول (افسوس کول) او د امتیازاتو زیاتوالی. که څه هم ډیری CVEs په مختلفو کټګوریو کې څو ځله شمیرل کیږي، په عمومي توګه ورته مسلې کال وروسته دوام لري. د مقالې په راتلونکې برخه کې، موږ به د دې زیانونو څخه د ګټې اخیستنې د مخنیوي لپاره د مختلفو محافظتي سکیمونو کارولو ارزونه وکړو.

عکس ایکس اینمکس

دندې

په دې مقاله کې موږ د لاندې پوښتنو ځوابولو اراده لرو:

• د مختلف لینکس توزیع امنیت څه دی؟ کوم محافظت میکانیزمونه د کرنل او کارن ځای غوښتنلیکونو کې شتون لري؟
• د مهال ویش په اوږدو کې د امنیتي میکانیزمونو پلي کول څنګه بدل شوي؟
• د هرې توزیع لپاره د کڅوړو او کتابتونونو اوسط انحصار څه دی؟
• د هر بائنری لپاره کوم محافظت پلي کیږي؟

د توزیع انتخاب

دا معلومه شوه چې د توزیع تاسیساتو په اړه دقیق احصایې موندل ګران دي، ځکه چې په ډیری قضیو کې د ډاونلوډ شمیره د اصلي نصبونو شمیر نه په ګوته کوي. په هرصورت، د یونیکس ډولونه د سرور سیسټمونو اکثریت جوړوي (په ویب سرورونو کې 69,2٪، شماري W3techs او نورې سرچینې)، او د دوی ونډه په دوامداره توګه وده کوي. پدې توګه ، زموږ د څیړنې لپاره موږ په پلیټ فارم کې د بکس څخه بهر موجود توزیع باندې تمرکز وکړ ګوګل کلاډ. په ځانګړې توګه، موږ لاندې OS غوره کړل:

توزیع/نسخه
کور
جوړول

OpenSUSE 12.4
4.12.14-95.3-ډیفالټ
#1 SMP چهارشنبه دسمبر 5 06:00:48 UTC 2018 (63a8d29)

دبیان 9 (پراخه)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP سه شنبه جنوري 15 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP د فبروري 1 14:54:57 UTC 2019

د Red Hat Enterprise Linux سرور 6.10 (سانتیاګو)
2.6.32-754.9.1.el6.x86_64
#1 SMP د نومبر 21 15:08:21 EST 2018

د Red Hat Enterprise Linux سرور 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP د نومبر 15 17:36:42 UTC 2018

اوبنټو 14.04 (د باور وړ طاهر)
4.4.0-140-عمومي

#166~14.04.1-Ubuntu SMP د شنبې په ورځ د نومبر 17 01:52:43 UTC 20…

اوبنټو 16.04 (Xenial Xerus)
4.15.0-1026-gcp
#27~16.04.1-Ubuntu SMP جمعه د دسمبر 7 09:59:47 UTC 2018

اوبنټو 18.04 (بایونک بیور)
4.15.0-1026-gcp
#27-Ubuntu SMP د دسمبر 6 18:27:01 UTC 2018

جدول 1

شننه

راځئ چې د ډیفالټ کرنل ترتیب مطالعه کړو ، په بیله بیا د بکس څخه بهر د هر توزیع د بسته بندۍ مدیر له لارې د موجود کڅوړو ملکیتونه. پدې توګه ، موږ یوازې د هر توزیع ډیفالټ عکسونو څخه کڅوړې په پام کې نیسو ، د بې ثباته زیرمو څخه کڅوړې له پامه غورځوو (لکه دبیان 'ټیسټینګ' عکسونه) او د دریمې ډلې کڅوړې (لکه د معیاري عکسونو څخه Nvidia کڅوړې). برسیره پردې، موږ د ګمرک کرنل تالیفات یا د امنیت سخت ترتیبات په پام کې نه نیسو.

د کرنل ترتیب تحلیل

موږ پر بنسټ د تحلیل سکریپټ پلي کړ وړیا kconfig چیکر. راځئ چې د نومول شوي توزیعاتو د بکس څخه بهر محافظت پیرامیټرې وګورو او له لیست سره یې پرتله کړو د ځان دفاع اصلي پروژه (KSPP). د هر ترتیب کولو اختیار لپاره، جدول 2 مطلوب ترتیب بیانوي: چک بکس د توزیع لپاره دی چې د KSSP سپارښتنو سره مطابقت لري (د شرایطو تشریح لپاره لاندې وګورئ). دلته; په راتلونکو مقالو کې به موږ تشریح کړو چې د دې امنیتي میتودونو څخه څومره رامینځته شوي او څنګه د دوی په نشتوالي کې سیسټم هیک کولی شو).

په عموم کې، نوي دانه د بکس څخه بهر سخت ترتیبات لري. د مثال په توګه، په 6.10 کرنل کې CentOS 6.10 او RHEL 2.6.32 ډیری مهمې ځانګړتیاوې نلري چې په نویو کرنلونو کې پلي شوي لکه SMAP، د RWX سخت اجازې، د ادرس تصادفي یا د کاپی2usr محافظت. دا باید په پام کې ونیول شي چې په جدول کې د ترتیب کولو ډیری اختیارونه د کرنل په زړو نسخو کې شتون نلري او په حقیقت کې د تطبیق وړ ندي - دا لاهم په جدول کې د مناسب محافظت نشتوالي په توګه ښودل شوي. په ورته ډول، که چیرې د ترتیب کولو اختیار په ورکړل شوي نسخه کې شتون ونلري، او امنیت ته اړتیا لري چې دا اختیار غیر فعال وي، دا یو مناسب ترتیب ګڼل کیږي.

یو بل ټکی چې باید په پام کې ونیول شي کله چې پایلې تشریح کړئ: د کرنل ځینې تشکیلات چې د برید سطح زیاتوي د امنیت لپاره هم کارول کیدی شي. په دې مثالونو کې اپروبونه او کیپروبونه، د کرنل ماډلونه، او BPF/eBPF شامل دي. زموږ سپارښتنه دا ده چې پورتني میکانیزمونه د ریښتیني محافظت چمتو کولو لپاره وکاروئ ، ځکه چې دا د کارولو لپاره غیر معمولي دي او د دوی استخراج داسې انګیرل کیږي چې ناوړه لوبغاړو لا دمخه په سیسټم کې پښه رامینځته کړې. مګر که دا اختیارونه فعال شوي وي، د سیسټم مدیر باید په فعاله توګه د ناوړه ګټه اخیستنې څارنه وکړي.

په جدول 2 کې ننوتو ته نور په پام کې نیولو سره، موږ ګورو چې عصري دانه د زیانونو څخه د ګټې اخیستنې په وړاندې د ساتنې لپاره ډیری اختیارونه وړاندې کوي لکه د معلوماتو لیک او سټیک / هپ فلو. په هرصورت، موږ ګورو چې حتی خورا وروستي مشهور توزیع لاهم ډیر پیچلي محافظت ندي پلي کړي (د بیلګې په توګه، د پیچونو سره امنیت) یا د کوډ بیا کارولو بریدونو پروړاندې عصري محافظت (د مثال په توګه د کوډ لپاره د R^X په څیر سکیمونو سره د تصادفي کولو ترکیب). د دې لپاره چې مسله نوره هم خرابه کړي، حتی دا نور پرمختللي دفاع د بریدونو بشپړ لړۍ څخه ساتنه نه کوي. له همدې امله، دا د سیسټم مدیرانو لپاره خورا مهم دی چې د حلونو سره سمارټ ترتیبات بشپړ کړي چې د چلولو وخت استحصال کشف او مخنیوي وړاندیز کوي.

د غوښتنلیک تحلیل

د حیرانتیا خبره نده، مختلف توزیع مختلف بسته ځانګړتیاوې لري، د تالیف کولو اختیارونه، د کتابتون انحصار، او داسې نور. اړوند توزیع او کڅوړې د لږ شمیر انحصارونو سره (د مثال په توګه ، په اوبنټو یا دیبیان کې کوریوټیل). د توپیرونو ارزولو لپاره، موږ ټول موجود کڅوړې ډاونلوډ کړې، د دوی منځپانګې یې استخراج کړې، او بائنری او انحصارونه یې تحلیل کړل. د هرې کڅوړې لپاره، موږ د نورو کڅوړو تعقیب ساتل چې دا پورې اړه لري، او د هر بائنری لپاره، موږ د هغې انحصار تعقیب کړ. په دې برخه کې موږ په لنډه توګه پایلې ته اشاره کوو.

توزیع

په مجموع کې، موږ د ټولو توزیع لپاره 361 کڅوړې ډاونلوډ کړې، یوازې د ډیفالټ عکسونو څخه کڅوړې استخراج کوو. موږ پرته له ELF اجرایوي کڅوړو څخه سترګې پټې کړې، لکه سرچینې، فونټونه، او نور. د فلټر کولو وروسته، 556 کڅوړې پاتې شوې، چې ټول 129 بائنری لري. د توزیع په اوږدو کې د کڅوړو او فایلونو ویش په انځور کې ښودل شوی. 569.

عکس ایکس اینمکس

تاسو شاید وګورئ چې د توزیع خورا عصري وي، په دې کې ډیرې کڅوړې او بائنریونه شامل دي، کوم چې منطقي دي. په هرصورت، د اوبنټو او ډیبیان کڅوړې د CentOS، SUSE او RHEL په پرتله ډیری نور بائنریونه (دواړه اجرایوي او متحرک ماډلونه او کتابتونونه) شامل دي، کوم چې په بالقوه توګه د اوبنټو او دیبیان د برید سطح اغیزه کوي (دا باید په یاد ولرئ چې شمیرې د ټولو نسخو ټول بائنری منعکس کوي. بسته، دا دی، ځینې فایلونه څو ځله تحلیل شوي). دا په ځانګړي توګه مهم دی کله چې تاسو د کڅوړو ترمینځ انحصار په پام کې ونیسئ. په دې توګه، په یوه کڅوړه بائنری کې زیانمنتیا کولی شي د ایکوسیستم ډیری برخې اغیزمنې کړي، لکه څنګه چې یو زیان منونکی کتابتون کولی شي په ټولو بائنریونو اغیزه وکړي چې دا واردوي. د پیل ټکي په توګه ، راځئ چې په مختلف عملیاتي سیسټمونو کې د کڅوړو ترمینځ د انحصار شمیر ویش وګورو:

عکس ایکس اینمکس

په نږدې ټولو توزیع کې، 60٪ کڅوړې لږترلږه 10 انحصار لري. سربیره پردې، ځینې کڅوړې د پام وړ لوی شمیر پورې تړاو لري (له 100 څخه ډیر). ورته د ریورس پیکج انحصار باندې تطبیق کیږي: لکه څنګه چې تمه کیده، یو څو کڅوړې په ویش کې د ډیری نورو کڅوړو لخوا کارول کیږي، نو په دې انتخاب کې زیانمنتیاوې لوړ خطر لري. د مثال په توګه، لاندې جدول 20 کڅوړې لیست کوي چې په SLES، Centos 7، Debian 9 او Ubuntu 18.04 کې د ډیرو متقابل انحصارونو سره (هر حجره بسته او د ریورس انحصار شمیره په ګوته کوي).

جدول 3

په زړه پورې حقیقت. که څه هم ټول OS تحلیل شوي د x86_64 معمارۍ لپاره جوړ شوي، او ډیری کڅوړې د x86_64 او x86 په توګه تعریف شوي جوړښت لري، کڅوړې اکثرا د نورو جوړښتونو لپاره بائنری لري، لکه څنګه چې په 5 شکل کې ښودل شوي. XNUMX.

عکس ایکس اینمکس

په راتلونکې برخه کې، موږ به د تحلیل شوي بائنری ځانګړتیاوو ته پام وکړو.

د بائنری فایل ساتنې احصایې

په مطلق حد کې ، تاسو اړتیا لرئ د خپلو موجوده بائنریونو لپاره د امنیت اختیارونو لومړني سیټ وپلټئ. د لینکس ډیری توزیعونه د سکریپټونو سره راځي چې دا ډول چیکونه ترسره کوي. د مثال په توګه، Debian/Ubuntu داسې سکریپټ لري. دلته د هغه د کار یوه بیلګه ده:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

سکریپټ پنځه چک کوي د ساتنې دندې:

• د موقعیت خپلواک اجرا وړ (PIE): دا په ګوته کوي چې ایا د برنامه متن برخه په حافظه کې لیږدول کیدی شي ترڅو تصادفي ترلاسه کړي که چیرې ASLR په کرنل کې فعال شوی وي.
• Stack Protected: آیا د Stack Canaries د سټک د ټکر بریدونو په وړاندې د ساتنې لپاره فعال شوي دي.
• سرچینه تقویه کړئ: ایا غیر خوندي دندې (د مثال په توګه ، strcpy) د دوی ډیر خوندي همکارانو سره ځای په ځای شوي ، او د چلولو په وخت کې چیک شوي تلیفونونه د دوی نه چیک شوي همکارانو سره بدل شوي (د مثال په توګه ، د __memcpy_chk پرځای memcpy).
• یوازې د لوستلو ځای بدلول (RELRO): ایا د ځای په ځای کولو جدول ننوتل یوازې د لوستلو لپاره په نښه شوي که چیرې دوی د اجرا کیدو دمخه پیل شوي وي.
• سمدستي پابند: ایا د رن ټایم لینکر د برنامې اجرا کولو دمخه ټولو حرکتونو ته اجازه ورکوي (دا د بشپړ RELRO سره مساوي دی).

ایا پورتني میکانیزمونه کافي دي؟ له بده مرغه نه. د پورته ټولو دفاع څخه د تیریدو لپاره پیژندل شوي لارې شتون لري، مګر دفاع چې سخته وي، د برید کونکي لپاره بار لوړ وي. د مثال په ډول، RELRO بای پاس میتودونه که چیرې PIE او سمدستي پابندۍ په عمل کې وي نو پلي کول به ډیر ستونزمن وي. په ورته ډول، بشپړ ASLR د کاري استحصال رامینځته کولو لپاره اضافي کار ته اړتیا لري. په هرصورت، پیچلي برید کونکي لا دمخه د داسې محافظتونو پوره کولو لپاره چمتو شوي دي: د دوی نشتوالی به په لازمي ډول هیک ګړندی کړي. نو دا اړینه ده چې دا اقدامات اړین وګڼل شي لږترلږه.

موږ غوښتل مطالعه کړو چې د پوښتنې په ویش کې څومره بائنری فایلونه د دې او دریو نورو میتودونو لخوا خوندي دي:

• د نه اجرا وړ بټ (NX) په هره سیمه کې د اعدام مخه نیسي چې باید د اجرا وړ نه وي، لکه د سټیک هپ، او داسې نور.
• RPATH/RUNPATH د اجرا کولو لاره په ګوته کوي چې د متحرک لوډر لخوا کارول کیږي ترڅو د ورته کتابتونونو موندلو لپاره. لومړی یو دی اجباري د هر عصري سیسټم لپاره: د دې نشتوالی برید کونکو ته اجازه ورکوي چې په خپل سري ډول د پیسو بار په حافظه کې ولیکي او لکه څنګه چې وي اجرا کړي. د دوهم لپاره، د پلي کولو غلطې لارې ترتیبونه د باور وړ کوډ په معرفي کولو کې مرسته کوي چې کولی شي د یو شمیر ستونزو لامل شي (د مثال په توګه د امتیازاتو زیاتوالیاو همدارنګه نورې ستونزې).
• د سټیک ټکر محافظت د بریدونو پروړاندې محافظت چمتو کوي چې د سټیک د حافظې نورو برخو (لکه هپ) ته د رسیدو لامل کیږي. د وروستي ناوړه ګټه اخیستنې په پام کې نیولو سره د سیسټمډ هپ ټکر زیانونه، موږ احساس وکړ چې دا مناسبه وه چې دا میکانیزم زموږ په ډیټا سیټ کې شامل کړو.

نو، پرته له نورو اډو، راځئ چې شمېر ته ښکته شي. جدول 4 او 5 په ترتیب سره د اجرا وړ فایلونو او د مختلف توزیع کتابتونونو تحلیل لنډیز لري.

• لکه څنګه چې تاسو لیدلی شئ، د NX محافظت په هر ځای کې پلي کیږي، د نادر استثنا سره. په ځانګړي توګه ، یو څوک کولی شي د CentOS ، RHEL او OpenSUSE په پرتله په اوبنټو او ډیبیان توزیع کې د دې یو څه ټیټ کارول یادونه وکړي.
• سټیک کانری په ډیری ځایونو کې ورک دي، په ځانګړې توګه د زړو دانو سره توزیع کې. ځینې ​​​​پرمختګ د Centos، RHEL، Debian او Ubuntu وروستي توزیع کې لیدل کیږي.
• د Debian او Ubuntu 18.04 استثنا سره، ډیری توزیع د PIE کمزوری ملاتړ لري.
• د سټیک ټکر محافظت په OpenSUSE، Centos 7 او RHEL 7 کې کمزوری دی، او په نورو کې په حقیقت کې شتون نلري.
• د عصري کرنلونو سره ټولې توزیعونه د RELRO لپاره یو څه ملاتړ لري ، د اوبنټو 18.04 سره لاره رهبري کوي او ډیبیان په دوهم کې راځي.

لکه څنګه چې مخکې یادونه وشوه، په دې جدول کې میټریکونه د بائنری فایل ټولو نسخو لپاره اوسط دي. که تاسو یوازې د فایلونو وروستي نسخې وګورئ، شمیرې به توپیر ولري (د مثال په توګه، وګورئ د PIE پلي کولو سره دبیان پرمختګ). سربیره پردې ، ډیری توزیعونه عموما یوازې په بائنری کې د یو څو دندو امنیت ازموینه کوي کله چې احصایې محاسبه کوي ، مګر زموږ تحلیل د دندو ریښتیني سلنه ښیې چې سخت شوي. له همدې امله، که له 5 څخه 50 افعال په بائنری کې خوندي شي، نو موږ به دا د 0,1 نمرې ورکړو، کوم چې د 10٪ فعالیتونو سره مطابقت لري چې پیاوړي کیږي.

جدول 4. د اجرا وړ فایلونو لپاره امنیتي ځانګړتیاوې په انځور کې ښودل شوي. 3 (د اجرا وړ فایلونو د ټول شمیر سلنې په توګه د اړونده دندو پلي کول)

جدول 5. د کتابتونونو لپاره امنیتي ځانګړتیاوې په انځور کې ښودل شوي. 3 (د اړونده دندو پلي کول د کتابتونونو د ټول شمیر سلنې په توګه)

نو ایا پرمختګ شته؟ په حقیقت کې شتون لري: دا د انفرادي توزیع لپاره د احصایو څخه لیدل کیدی شي (د مثال په توګه، Debian)، او همدارنګه د پورته جدولونو څخه. د مثال په توګه په انځور کې. شکل 6 د اوبنټو LTS 5 په دریو پرله پسې توزیعونو کې د محافظت میکانیزمونو پلي کول ښیې (موږ د سټیک ټکر محافظت احصایې لرې کړې). موږ ګورو چې له نسخې څخه نسخې ته ډیر او ډیر فایلونه د سټیک کانریونو ملاتړ کوي ، او همدارنګه ډیر او ډیر بائنری د بشپړ RELRO محافظت سره لیږل شوي.

عکس ایکس اینمکس

له بده مرغه، په مختلفو توزیعونو کې یو شمیر اجرایوي فایلونه لا تر اوسه پورتني محافظتونه نلري. د مثال په توګه، اوبنټو 18.04 ته په کتلو سره، تاسو به د ngetty بائنری (د ګیټی بدیل) وګورئ، په بیله بیا د mksh او lksh شیلونه، د picolisp ژباړونکي، د nvidia-cuda-toolkit کڅوړې (د GPU ګړندۍ غوښتنلیکونو لپاره مشهور بسته لکه د ماشین زده کړې چوکاټ)، او klibc -utils. په ورته ډول، د mandos-client بائنری (یوه اداري وسیله چې تاسو ته اجازه درکوي په اتوماتيک ډول د کوډ شوي فایل سیسټمونو سره ماشینونه ریبوټ کړئ) او همدارنګه rsh-redone-client (د rsh او rlogin بیا پلي کول) پرته د NX محافظت کښتۍ، که څه هم دوی د SUID حقونه لري: (همدارنګه، ډیری سوډ بائنری د بنسټیز محافظت نشتوالی لکه د سټیک کانریز (د مثال په توګه، د Xorg پیکج څخه Xorg.wrap بائنری).

لنډیز او پای تبصرې

پدې مقاله کې ، موږ د عصري لینکس توزیع ډیری امنیتي ځانګړتیاوې په ګوته کړې. تحلیل ښودلې چې د اوبنټو LTS وروستي توزیع (18.04) په اوسط ډول د نسبتا نوي کرنلونو لکه اوبنټو 14.04 ، 12.04 او ډیبیان 9 سره د توزیعونو ترمینځ خورا قوي OS او غوښتنلیک کچه محافظت پلي کوي. په هرصورت ، ازمول شوي توزیع CentOS ، RHEL او OpenSUSE زموږ په سیټ کې د ډیفالټ لخوا دوی د کڅوړو خورا سخت سیټ تولیدوي ، او په وروستي نسخو کې (CentOS او RHEL) دوی د ډیبیان میشته سیالانو (Debian او Ubuntu) په پرتله د سټیک ټکر محافظت لوړه سلنه لري. د CentOS او RedHat نسخو پرتله کول، موږ د 6 څخه تر 7 نسخو پورې د سټیک کانریونو او RELRO پلي کولو کې لوی پرمختګونه ګورو، مګر په اوسط ډول CentOS د RHEL په پرتله ډیر ځانګړتیاوې لري. په عموم کې ، ټولې توزیع باید د PIE محافظت ته ځانګړې پاملرنه وکړي ، کوم چې د Debian 9 او Ubuntu 18.04 استثنا سره زموږ په ډیټاسیټ کې د بائنریونو 10٪ څخه لږ پلي کیږي.

په پای کې، دا باید په پام کې ونیول شي چې که څه هم موږ څیړنه په لاسي ډول ترسره کړې، ډیری امنیتي وسایل شتون لري (د بیلګې په توګه. لینکس, ټيرګ, هبل)، کوم چې تحلیل ترسره کوي او د غیر خوندي ترتیباتو څخه مخنیوي کې مرسته کوي. له بده مرغه، حتی په معقول ترتیب کې قوي محافظت د استحصال نشتوالی تضمین نه کوي. له همدې امله موږ په کلکه باور لرو چې ډاډ ترلاسه کول حیاتي دي په ریښتیني وخت کې د باور وړ نظارت او د بریدونو مخنیوید استثمار په نمونو تمرکز او د هغوی مخنیوی.

سرچینه: www.habr.com