Linux може отримати Killswitch
Для Linux запропонували Killswitch, що дозволить тимчасово вимикати конкретні вразливі функції ядра прямо під час роботи системи. Відповідні патчі представив розробник Саша Левін, який входить до консультативної ради Linux Foundation.
Поява такої пропозиції зрозуміла — нещодавно в Linux виявили одразу дві серйозні вразливості, зокрема Copy Fail 2: Electric Boogaloo та Dirty Frag, де між публічним розголосом та виправленням утворилося небезпечне вікно. Ідея Killswitch саме у тому, щоб закрити саме цей проміжок.
Як це має працювати
Адміністратор зможе вимкнути конкретну проблемну функцію ядра. Після цього виклики до неї завершуватимуться помилкою, замість того щоб доходити до вразливого коду. Тобто це не виправляє баг та не робить код безпечним, а тимчасово відокремлює небезпечну ділянку, поки готується відповідний патч.
Killswitch має працювати через securityfs та буде корисним переважно для підсистем, без яких система може певний час прожити. Адже у деяких випадках тимчасова втрата частини функціональності може бути меншою проблемою, ніж залишити відомий вразливий код.
Такий стан зберігатиметься, поки адміністратор сам не вимкне механізм або поки систему не перезавантажать.
Наразі думки спільноти щодо червоної кнопки розділились. Частина розробників бачить у Killswitch корисний тимчасовий захист, що може допомогти великим інфраструктурам швидко вимкнути вразливу функцію ядра, поки патчу ще немає. Але також є питання до стабільності, можливих помилок в конфігурації та ризику зловживання.
Як вам така ідея? Чи потрібен Linux аварійний захист, чи це надто небезпечний інструмент?
6 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівВмикання або вимикання компонентів ОС це вже ченж, що є катастрофою для продакшена. То ж навіть запуск кілсвіча це тільки в офлайні, ну то вже і ребутнуть можна коли система офлайн :)
Повертаючись до цієї теми:
github.com/jnuyens/modulejail
Ну, в принипі, чо ні. Інколи дійсно вкрай проблемно перезбирати ядро при наявності якихось блобів-драйверів, які не сумісні з новою версією ядра. А інколи бувають системи, яки просто неможна перезавантажувати (або вкрай важко і треба планувати і це може займати довгий час.
Тоді дійсно краще вимкнути вразливу функцію.
Але є одне але. Я б волів мати якийсь лог звернення до системних функцій, щоб побачити, а чи було звернення до цієї функції протягом останньої години, суток та з моменту завантаження — типу лічильник. І можливість ввімкнути повний лог, щоб подивитись який саме процес її викликає, якщо лічильник не нульовий — бо можна-ж вимкнути функцію і покласти систему...
Ну сісколи мабуть можливо моніторити, а ось співвіднести модуль який планується кілсвічнути з ними(колами) це складніше. Взагалі ідея трохи авантюрна, імхо. Будуть випадки вистрілювання в ногу, руку, ще щось.
Falco та Tetragon вміють збирати інфо по module load, можна так спробувати
відсіяти які не використовуються
Будуть, але це вже відповідальність адміністратора. Це як зі зброєю — краще мати для захисту, хоча звісно, хтось і застрелиться. Треба навчати і контролювати. Давати такий доступ в юзерспейс, звісно, не треба.
Ще як варіант обійтися ebpf, якщо фічу не підтримають. Але це мабуть складніше.