Чому патчі з безпекою не включаються до ядра ванілі?

22

Які причини того, що grsecurityпатчі (або захисні функції, які він приносить) не включаються до ядра за замовчуванням. Якщо дивитися на переваги для безпеки, то здається, що ванільне ядро є досить незахищеним.

Якщо це компроміс (деякі додатки, де ви хочете уникнути заходів безпеки), здається, що це grsecurityможе бути опція для включення у ванільному ядрі.

Маючи так багато речей у ванільному ядрі, мені важко зрозуміти причини, через які спільнота не хоче включати grsecurity.

linux kernel grsecurity

— людство і погляд
джерело

Здається, це є політичною проблемою. Здається, Торвальдс вважає, що деякі з їхніх латок - це сміття. Також див. Рекомендації щодо безпеки Qualys - зіткнення стека та інші вразливості CONFIG_VMAP_STACK, refcount_t UAF та ігнорований метод обходу / rootkit захищеного захисного завантаження у списку розсилки OSS-Security.

З минулих пропозицій у списках розсилки криптовалют ядра я та інші були поміщені у відро Торвельдс мітками "безумними". Тож не лише люди з небезпеки, які стикаються з проблемою. Також дивіться випадкові випадки: попередження компілятора тиші та виправлення гонки . Потік - це дискусія про надання dmesg для драйверів, які використовують {u} випадковий до його готовності. (Ви можете не знати, але ряд драйверів користується пристроями перед тим, як їх належним чином

23

(Я розробник грубої безпеки.)

Відповідь jsbillings заснована на публікації електронної пошти, обговореній у статті LWN .

Важливим контекстом є те, що ні безпека, ні розробники PaX не були залучені до обговорення цього списку розсилки. Коментар команди PaX до статті LWN очищує це. Ми ніколи не надсилали патчі для включення магістралі. Однією з простих причин є те, що ми з тими ідеями та реалізаціями, які upstreaming не вирішить. Крім того, нам доведеться брати участь у набридливих аргументах списку розсилки з групою розробників, які дуже захищені (див. Мою презентацію H2HC 2012для більшого обговорення цього питання). У нас обмежений час та ресурси, тому ми вирішимо витратити їх на найефективніший спосіб: створити технологію безпеки завтра та зробити її доступною для всіх безкоштовно. Як згадує Команда PaX у своєму коментарі, ми маємо особливий охоплюючий погляд на безпеку, і, таким чином, не вважаємо, що є багато заслуг у розщепленні та передачі окремих функцій.

— Бред Шпенглер
джерело

Мені сподобалось посилання на цікаву статтю LWN. Дякую. Я все ще в заплутаному стані читаю думку про те, що група розробників Kernel буде "дуже сильно захищеною". У мене, звичайно, немає ніякого розуміння, але це здається хвилюючим :(. Плутанина полягає в тому, що я вважаю, що безпека є одним із "найсильніших аргументів" для OpenSource та Linux. На даний момент я відчуваю досить загрозу моїй системі на базі ubuntu. залишається трохи залишилися позаду с, що було б «більше очей можуть виглядати» -Security ОС Верт якщо ми не знали , як я Grsecurity у всякому разі, спасибі за це ?.

— humanityANDpeace

10

Здається, що у розробників грубої безпеки в минулому виникали проблеми, що переконували Лінус прийняти зміни в ядрі. Здається, проблеми:

Подаючи гігантську крапку коду і не розбиваючи її на шматки
Лінус вважає багато змін "божевільними", що, мабуть, спосіб Лінуса сказати, що це не працює з його планами на майбутній розвиток.

— jsbillings
джерело

Це досить цікаві моменти. Ще навчаюсь - я навіть не знав про BLOB (це, напевно, щось, що не є відкритим джерелом). Ну Інформація хороша. Якщо вказані причини правдиві, це все одно прикро. Мені подобається ідея покращення безпеки, пов’язаної з патчетом безпечності.

— людствоANDpeace

1

@humanityANDpeace "крапля" може означати "бінарний великий об'єкт" (як правило, в базі даних, але іноді і в інших місцях), або він може бути сленговим для "великого шматка будь-якого". У цьому випадку я вважаю, що jsbillings означав це як останнє: великий шматок вихідного коду, який далі не підрозділяється. Будучи самим програмістом, я точно знаю, як засмучувати це може працювати, не кажучи вже про перегляд.

— CVn