کیس کوک، CSO سابق kernel.org و رهبر تیم امنیتی اوبونتو، که اکنون برای Google برای ایمن سازی اندروید و ChromeOS کار می کند، نسبت به روند فعلی رفع اشکالات در شاخه های پایدار هسته ابراز نگرانی کرد. هر هفته، حدود صد اصلاح در شاخه های پایدار گنجانده می شود و پس از بسته شدن پنجره پذیرش تغییرات به نسخه بعدی، به هزار مورد می رسد (نگهدارکنندگان تا زمانی که پنجره بسته شود، اصلاحات را نگه می دارند و پس از تشکیل "-rc1" آنها را انجام می دهند. موارد انباشته شده را به یکباره منتشر کنید)، که بسیار زیاد است و برای محصولات تعمیر و نگهداری مبتنی بر هسته لینوکس به کار زیادی نیاز دارد.
به گفته کیز، فرآیند کار با خطاها در کرنل مورد توجه قرار نمی گیرد و هسته حداقل 100 توسعه دهنده اضافی برای کار هماهنگ در این زمینه ندارد. توسعه دهندگان هسته هسته به طور منظم اشکالات را برطرف می کنند، اما هیچ تضمینی وجود ندارد که این اصلاحات به انواع هسته مورد استفاده توسط اشخاص ثالث منتقل شوند. کاربران محصولات مختلف مبتنی بر هسته لینوکس نیز راهی برای کنترل رفع اشکالات و استفاده از هسته در دستگاه هایشان ندارند. فروشندگان در نهایت مسئول امنیت محصولات خود هستند، اما با نرخ وصله بسیار بالا در شاخه های هسته پایدار، با انتخاب بین backporting همه وصله ها، پورت انتخابی مهم ترین ها یا نادیده گرفتن همه وصله ها مواجه شدند.
راه‌حل بهینه این است که فقط مهم‌ترین رفع‌ها و آسیب‌پذیری‌ها را انتقال دهیم، اما جداسازی چنین خطاهایی از جریان عمومی مشکل اصلی است. بیشتر مشکلاتی که ظاهر می شود به دلیل استفاده از زبان C است که در کار با حافظه و اشاره گرها دقت زیادی می طلبد. بدتر از آن، بسیاری از رفع آسیب‌پذیری‌های بالقوه با شناسه‌های CVE ارائه نمی‌شوند، یا مدتی پس از انتشار وصله، چنین شناسه‌ای را دریافت می‌کنند. در چنین شرایطی، برای سازندگان بسیار دشوار است که اصلاحات جزئی را از مشکلات امنیتی اصلی جدا کنند. طبق آمار، بیش از 40 درصد از آسیب‌پذیری‌ها قبل از تخصیص CVE رفع می‌شوند و میانگین تأخیر بین انتشار یک پچ و تخصیص یک CVE سه ماه است (یعنی در ابتدا، وصله به‌عنوان یک وصله معمول تلقی می‌شود. اشکال، اما تنها پس از چند ماه مشخص می شود که آسیب پذیری رفع شده است).
در نتیجه، بدون داشتن یک شعبه مجزا با رفع آسیب‌پذیری‌ها و بدون دریافت اطلاعات در مورد اتصال امنیتی یک مشکل خاص، تولیدکنندگان محصولات مبتنی بر هسته لینوکس موکول می‌شوند تا به طور مداوم همه اصلاحات را از شاخه‌های پایدار تازه منتقل کنند. اما این کار به نیروی کار زیادی نیاز دارد و به دلیل ترس از تغییرات قهقرایی که می تواند عملکرد طبیعی محصول را مختل کند با مقاومت در شرکت ها مواجه می شود.
به یاد داشته باشید که طبق گفته لینوس توروالدز، همه خطاها مهم هستند و آسیب پذیری ها را نباید از انواع دیگر خطاها جدا کرد و به یک دسته با اولویت بالاتر اختصاص داد. این نظر با این واقعیت توضیح داده می شود که برای یک توسعه دهنده معمولی که در مسائل امنیتی تخصص ندارد، ارتباط بین یک تعمیر و یک آسیب پذیری بالقوه واضح نیست (برای بسیاری از اصلاحات، فقط یک ممیزی جداگانه به شما امکان می دهد بفهمید که آنها به امنیت مربوط می شوند. ). به گفته لینوس، این به تیم‌های امنیتی تیم‌هایی است که مسئولیت نگهداری بسته‌های هسته در توزیع‌های لینوکس را بر عهده دارند تا آسیب‌پذیری‌های احتمالی را از جریان وصله عمومی جدا کنند.
کیس کوک معتقد است که تنها راه حل برای ایمن نگه داشتن هسته با هزینه طولانی مدت معقول این است که شرکت ها مهندسان درگیر در انتقال وصله ها را به ساخت های هسته محلی منتقل کنند تا به طور مشترک و هماهنگ برای حفظ وصله ها و آسیب پذیری ها در هسته بالادستی کار کنند. در شکل فعلی آن، بسیاری از تولیدکنندگان از آخرین نسخه هسته در محصولات خود استفاده نمی کنند و به تنهایی از اصلاحات پشتیبان استفاده می کنند. معلوم می شود که مهندسان در شرکت های مختلف کار یکدیگر را تکرار می کنند و همان مشکل را حل می کنند.
به عنوان مثال، اگر 10 شرکت، هر کدام با یک مهندس پشتیبان اصلاحات یکسان، آن مهندسان را برای رفع اشکالات در بالادست هدایت کنند، به جای انتقال یک اصلاح واحد، می توانند 10 اشکال مختلف را برای منافع عمومی برطرف کنند یا به بررسی تغییرات پیشنهادی بپیوندند. از گنجاندن کد باگ در هسته جلوگیری کنید. منابع همچنین می توانند به ایجاد ابزارهای جدید برای آزمایش و تجزیه و تحلیل کد اختصاص داده شوند، که در مراحل اولیه امکان شناسایی خودکار کلاس های معمولی از خطاهایی که بارها و بارها ظاهر می شوند را فراهم می کند.
Kees Cook همچنین استفاده فعال تر از تست های خودکار و فازی را به طور مستقیم در فرآیند توسعه هسته، استفاده از سیستم های یکپارچه سازی مداوم و کنار گذاشتن مدیریت توسعه قدیمی از طریق ایمیل پیشنهاد می کند. در حال حاضر، آزمایش مؤثر با این واقعیت که فرآیندهای آزمایش اصلی از توسعه جدا شده اند و پس از شکل گیری نسخه ها رخ می دهند، مختل شده است. Keys همچنین استفاده از زبان های امن تر مانند Rust را برای کاهش باگ ها توصیه می کند.
منبع: opennet.ru