>> UDEREF для x86 (не x86_64) на базе механизма сегментации памяти.
> Это тот, где адресное пространство делится на два куска по полтора гига? Нет, этот тот, для реализации которого всего-навсего используется сегментация, без наложения каких-либо ограничений на количество адресуемой памяти. Реализация UDEREF для x86 - самя быстрая, самая надёжная и бесплатная в плане производительности. Но вот не место сегментации в ядре, по мнению Торвальдса, и всё тут.
Лимит в полтора гига был у SEGMEXEC, который нужен был для реализации W^X на старых процессорах без поддержки NX-бита. К тому же, SEGMEXEC легко отключается для отдельно взятого исполняемого файла посредством его пометки соответствующим PaX-флагом (маленькая s) или непометки (большая S) в случае soft mode. Но зачем пользователям возможность выбора, правильно? ;)
> Мне та идея тоже не очень нравилась, в наше время полтора
> гига для одной программы — не так и много.
Торвальдс высказался в адрес сегментации как таковой и сделал это отнюдь не в "наше время". А впоследствии, уже не так давно, добавил, по смыслу, следующее: мол, правильно мы тогда не стали связываться с [UDEREF] (название не упомянул), ведь теперь поддержка такого механизма защиты реализована в процессорах. Вот только он забыл рассказать, что даже SMEP (не SMAP), который является более слабым подмножеством UDEREF на тот момент был только в самых новых процессорах, вот как сейчас SMAP. А SMAP соответственно не было нигде вообще. И по сей день множество пользователей линукса на устройствах с не самыми новыми процессорами остаются без аналогичного механизма защиты (даже если на минуту забыть, как просто он отключается посредством записи в CR4). Но это ведь всё лирика, не так ли? :) Ведь если Торвальдс что-то сказал, значит, это не лишено смысла...
> Да, я понимаю. Но как раз эту ситуацию закрытие патчей только ухудшает.
А вот и нет, не всё так просто. ;)
> Навешивание лапши на уши это не остановит — существующих идей и
Пусть навешивают. Спустя какое-то время по ним ударит технологический долг:
- Кем-то будут найдены и опубликованы уязвимости в их неумелой копипасте (а spender раскроет содержимоей файлов с описанием этих уязвимостей, хэши для которых он уже опубликовал) - раз.
- Сложность эксплуатации уязвимостей останется примерно на прежнем уровне, и мы все сможем в этом убедиться, читая PoC-эксплойты и статьи по их разбору - два.
- Некоторую копипасту, с которой будут возникать проблемы, придётся отключать ко времени очередного мажорного релиза ядра, потому что в среде разработчиков основного ядра нет людей, которые смогут разобраться, как её починить - три.
> патчей хватит ещё не на один год портирования и пиара. Но
Сложность портирования кода из старых патчей в новые верси ядер будет расти, увеличивая вероятность допущения ошибок. Больше технологического долга богу технологического долга. :)
> с закрытием патчей противопоставить этому пиару будет уже нечего. Пройдёт пол
С высокой вероятностью, даже последний патч для 4.9.24 (или его неофициальное развитие) будет содержать добротную реализацию механизмов защиты, которая окажется актуальной для смягчения последствий эксплуатации свежеопубликованных уязвимостей.
> года, выйдет несколько версий ядра, и патчи устареют. Какими аргументами тогда
> отвечать на очередной пиар LF? "всё это давно было в grsec"?
На очередной пиар LF всегда найдутся аргументы, вот только grsec не вёл и, похоже, не будет бороться с LF на этом поприще. Вы всё исходите из того, что у проекта есть какие-то особо ценные для него коммерческие интересы, которые необходимо отстаивать в активной борьбе с конкурентами. Но это почти полностью не так. На данный момент, на сколько я понял, для разработчиков grsec более актуально возвращение былой мотивации к работе над проектом, а также лишение плагиаторов источника свежей копипасты.
> — "да, _было_, и больше не поддерживается, а наши изменения поддерживаются,
> продолжают развиваться и совершенствоваться" — ответят LF, и, увы, будут правы.
Будут правы, говорите? Значит, надеетесь, что KSPP сработает на совесть и механизмы защиты в основном коде ядра окажутся дееспособны. Ну вот и поглядим. :) Мой прогноз: и через 5 лет SMEP и SMAP будут всё так же просто и надёжно отключаться при эксплуатации, как и в недавнем случае, который я приводил.
> На безрыбье и рак рыба.
Something is better than nothing, да. ;)
> Ну, я знаю о grsecurity благодаря hardened gentoo. Да и если поспрашивать
> у линуксоидов "а вы знаете про специально модифицированный защищённый линукс, в
> котором безопасность на первом месте?" отвечают "слышали про такое то ли
> в генту то ли в арче", если вообще о таком слышали.
И это, по-вашему, целевая клиентская группа grsec? Если кто-то услышал о grsec, это ещё не значит, что с такой рекламы будет конверсия. Целевая аудитория - это CISO и специалисты в области защиты информации, которые и без рекламы прекрасно осведомляются о существовании grsec и его возможностях, просто в силу должностных обязанностей и круга компетенций.
> Не только в коммерческой плоскости. Я имею ввиду, что эта реклама популяризировала
> безопасность как таковую. Без него упадёт спрос на "правильную" безопасность в
> целом, ведь пользователи просто не будут о ней знать.
Как выяснилось, представление о "правильной" безопасности такая "реклама" если и сформировала, то лишь у небольшого числа пользователей. Остальные сейчас весело поддерживают инициативу KSPP, следуя логике, сходной той, что вы озвучивали: вот в ядре скоро появятся многие или даже почти все фичи grsec и он станет не нужен, так давайте же все, кто может, посодействуем этому полезному процессу, во благо безопасности большинства пользователей. ;)
Бессистемное мышление на уровне "фич" победить очень сложно. Над этим надо целенаправленно работать: книги, например, писать. А "реклама" - только и породила, что "сообщество" в кавычках.
> А это уже упущение grsec-овцев как маркетологов, которые недостаточно рекламировали свои
> достижения в сообществе. Ну и упущение сообщества, недостаточно распространившего информацию про grsec.
Если "фичи" взяты на вооружение "конкурентами", в глазах клиента первенство уже не имеет значения. Проект уже потерял некоторых клиентов, которые были вполне себе в курсе, кто был первым, но поверили пиару LF, посчитав, что платить за grsec больше не имеет смысла. Это произошло именно потому, что для тех клиентов деятельность KSPP выглядит как добросовестное включения функционала grsec в официальный код ядра.
К слову, даже если б LF сообщала, что достижения KSPP по большему счёту основаны на наработках grsec, но (!) не обозревала бы при этом реальную картину в плане эффективности того, что есть в grsec, против эффективности того, что есть в апстриме... Для grsec это означало бы ровно то, что LF и его члены пытаются нажиться на репутации проекта, и не более.
> На случай если нас кто-то ещё читает... TL;DR:
> Есть апстрим, он считает, что баги есть баги[1], security-баги это просто баги,
> которые нужно чинить, так же как и любые другие.
...и при этом намеренно скрывает информацию о security impact таких "просто багов" в случаях, когда такая информация _у него имеется_. ;) Якобы чтобы скрипт-киддис не помогать. Как будто скрипт-киддис читают коммиты и сами пишут эксплойты. Но в любом случае: или просто баги, или сокрытие известной информации о security impact. Или крестик снимите, или штаны наденьте, как говорится.
> И нет причин кардинально менять подход, рисковать стабильностью, удобством обслуживания или производительностью ядра у конечного пользователя для того, чтобы усложнить использование некоторых багов
Вы ретранслируете классический пример Fear, Uncertainty and Doubt. Во-первых, стабильностью рискуют при внесении совершенно любых изменений, и безопасность тут не исключение. Вопрос лишь в приоритетах и соответственно в оценке значимости. Я лично имел гораздо больше проблем со стабильностью в LTS-версиях ядер из-за ошибок в патчах апстрима и в относительно свежем коде, как при замене драйвера Ext3 на драйвер Ext4 в своё время, чем связанных с grsec.
Кроме того, дистрибутивные ядра включают множество отнюдь не самых востребованных опций сборки, для которых в описании прямым текстом указана просадка в производительности до 2-3-5%. И многих ли волнует такое небережное отношение к производительности? ;) Пользуются тем, что включено по умолчанию.
Во-вторых, для кого-то безопасность не стоит на первом месте, а кто-то - вполне готов платить и стабильностью, и производительностью, в большей или меньшей степени. Grsec всегда предоставлял и предсотавляет пользователям этот выбор. В отличие от апстрима, который из лучших побуждений и в духе Свободного ПО предпочитает решать всё за всех. Об этом тоже следует напоминать при случае. А то развели, понимаешь, дилемму на ровном месте и пыжатся. ;)
> тем более, что самих багов это в любом случае не исправит.
В плане безопасности это вообще не аргумент. Важен impact и насколько он поддаётся mitigation.
> Любые патчи в ядро должны проходить те же этапы, что и все.
Вот бы так в силовые структуры и армию людей набирали: по тем же критериям, что и всех. И в разведке так же работали: по тем же критериям, что и все. Например, вот, разбился вражеский самолёт где-то в океане, вынесло на берег труп. При трупе планшет, а в планшете - ценные документы с описанием предстоящих военных операций врага. Что должна делать разведка? Правильно: сразу же решить, что документы подлинные, и тут же сообщить о них в штаб армии. А в штабе, в свою очередь, должны предпринять соответствующие меры: подвинуть войска, откуда возможно - куда надо, и т.п.. Не так ли? :)
Потому что кто ж в здравом уме будет превращать охранную, оперативно-розыскную, разведывательную и военную деятельность в рассадник явной паранойи (а что ж это ещё, как не паранойя, да?)? Кто ж будет отказываться от бритыв Оккама: подозревать что-то, преумножать эти самые сущности, тратить ресурсы, подстраивать под паранойю все процессы? В здравом уме - да никто! Все работают и превосходно себе зарабатывают совершенно иначе, и правильно делают! А то, что безопасность должна восприниматься по-иному, как нечто особенное - так это всё выдумки мастурбирующих обезьян, у которых просто неимоверно раздутое эго, и которых ни один уважающий себя человек, конечно же, не воспринимает всерьёз. :) Всё верно, всё правильно, всё нормально, в рамках здравого смысла и принятых, отработанных процессов. Так и должно быть. :)
Не удержался от аналогии, да.
> И есть pax/grsecurity, осознающие, что для успешной защиты надо исправить все ошибки,
Не "исправить все ошибки", а постараться предотвратить их эксплуатацию с последствиями в случае успеха более серьёзными, чем отказ в обслуживании. Ниже вы правильно написали, а тут, видимо, опечатка.
> баги безопасности — это особый вид багов
И так считает практически вся ИТ-индустрия, кроме Великого Руководителя Торвальдса.
> и продолжают создавать множество[2] сейчас уже общеизвестных и общедоступных систем защиты
Ссылка на RAP FAQ, видимо, не ко "множеству", а к "продолжают создавать".
> значительные изменения для защиты ядра. Их подход сильно отличается от подхода
> апстрима, и в таком виде в апстрим принят не будет. Хотя идеи-то отличные...
Некоторые вещи ни в каком (!) виде приняты не будут, как тот же UDEREF. У его реализации на базе PCID, разве что, есть какие-то шансы.
> Поэтому появился проект KSPP, который пытается хотя бы часть идей из grsec-патчей
> портировать в ядро. Конечно отдельных идей недостаточно, по-настоящему они работают
> только в комплексе
...и только лишь будучи качественно реализованными и бдительно сопровождаемыми.
> и по-отдельности лишь закрывают один из путей, не давая защиты в целом.
А в некоторых случаях - как закрывают, так и открывают. ;) Наглядный пример: простота и надёжность откличения SMEP и SMAP в процессе эксплуатации.
> Но что-то лучше, чем ничего.
Что-то, что _сущесвтенно_ лучше, чем ничего - это Grsecurity, со всей его неполнотой и несовершенством.
> И KSPP надеятся, что может быть со временем удастся достичь нужного уровня, хотя сами
> понимают, что их попытки намного слабее работ grsec.
При этом и атакующая сторона не собирается сидеть на месте. Нет никакого нужного уровня. Безопасность - это процесс, гонка вооружений. Которую на данный момент, строго говоря, проигрывает даже Grsecurity (что мы видим даже на примере некоторых публикуемых уязвимостей, вроде dirty COW). Вопрос лишь в том, с каким отставанием, поскольку в некоторых случаях достигнутого уровня может оказаться достаточно для относительно успешной защиты от реальных атак.
> Но так или иначе, KSPP старательно вносят отдельные идеи в ядро.
К чему оценочные суждения, вроде "старательно"? Благими намерениям известная дорога вымощена. Старательно они внесли (вперёд ногами) KASLR, например.
> Их спонсирует Linux Foundation
Не совсем так. LF спонсирует CII, которая в свою очередь спонсирует лишь некоторых людей из тех, кто так или иначе работает над безопасностью в апстриме. Кэйс Кук, например, работает на одно из подразделений гугла и там же получает зарплату.
> и рекламирует "достижения" KSPP по улучшению безопасности,
LF, таким образом, лишь имеет некоторое прямое отношение и старательно :) сопровождает деятельность KSPP в информационном пространстве.
> полностью "забывая"[3][4] сказать, что все эти изменения были взяты из pax/grsec[5],
> и там они имеют более высокое качество и обеспечивают куда большую безопасность.
Да, но для сообщества, пожалуй, гораздо важнее то, что результаты KSPP на данный момент не имеют, если можно так выразиться, практически никакого качества.
> Выходит дурацкая ситуация, когда половинчатые незаконченные скопированные решения
> рекламируются, как огромное достижение
И опять же, важно не столько то, как они рекламируются, а что за всем этим стоит. Какого рода причины, процессы, чьи интересы и средства их достижения. Допустим, завтра LF публично раскается и выпустить материал, где честно и слёзно расскажет, как всё плохо. Даже если так, что дальше?
Что, если сообщество останется при иллюзии, будто бы _в рамках принятого и навязанного апстримом подхода_ будут достигнуты какие-то реальные результаты в какой-то там перспективе? Оно останется ровно при том же дырявом ядре и лишь отодвинет момент полного разочарования в будущее, выдав апстриму огромный кредит доверия, который тот вовсе не собирается погашать.
Таким образом, я предлагаю такую точку зрения, что "дурацкая ситуация", о которой вы говорите - это лишь хороший повод задуматься над ситуацией _в целом_ и постараться разобраться в ней.
> при этом о grsec — реальных авторах этих
> решений и реальных достижениях полностью умалчивается.
Да, только я изначально не уточнил, что простое упоминание grsec как источника идей и реализаций - было бы ни чем иным, как попыткой примазаться к репутации проекта. Упоминание grsec было бы целиком уместно лишь в контексте попыток дать честную оценку результатам деятельности и перспективам KSPP. И лишь в некотором смысле уместным - в контексте признания превосходства grsec (проекту бы это как минимум не помешало, но сообществу-то что с того?).
> Это также вводит в заблуждение
> сообщество, создавая ощущение ложной безопасности, ложных шагов вперёд, когда по факту
> это шаг назад по сравнению с тем, что уже достигнуто в grsec,
К слову, с этим утверждением в такой форме будут спорить все из противоположного лагеря.
По факту это скорее отсутствие _должных_ шагов вперёд: изменения подхода к безопасности в целом, отказа от субъективных оценочных суждений (см. пример с UDEREF выше), принятия модели угроз, осмысленной планомерной работы в рамках принятой модели, скорейшего (!) принятия наиболее значимых (а не наиболее удобных для "портирования", как сейчас) изменений из grsec или реализации аналогичных с привлечением компетентных исполнителей и меинтейнеров (попробуй найти).
> да и местами в других операционках. Такое шапкозакидательство подошло бы
> для рекламы стирального порошка, но не для освещения вопросов безопасности.
Не при работе над безопасностью. Одно бы только освещение вызывало вопросы - кого бы это волновало...
> Помочь с ситуацией могло бы сообщество и другие разработчики, в том числе
> KSPP, но они этого не сделали.
Другие разработчики, в том числе KSPP, приняли непосредственное участие в создании ситуации. Кто там мог бы с ней "помочь" - это уже следующий вопрос. Есть мнение, что в действительности - практически никто. А в теории-то, конечно, и сообщество, и люди из апстрима, и LF... Если бы да кабы. :\
> Grsec-овцам надоело смотреть на то, как их работы используют для рекламы чужих
> успехов по копипасту и впечатления ложной безопасностью, и они перестали выкладывать
> свои патчи в общий доступ.
Используют не только и не столько для рекламы, а в качестве источника для низкокачественной копипасты и бесплатных исправлений для этой копипасты.
> Но "мосты не сожжены: патчи как пропали из общего доступа, так могут
> и вернуться. [...] У сообщества есть шанс. [...] Главная помощь, которую
> могло и, лично я уверен, всё ещё может (в принципе) оказать
> сообщество - это поддержка в медийном пространстве и чёткое формулирование спроса
> на реальную безопасность в линуксе."
Сообщество может, но не знает и не хочет. :)
> Надеюсь, ничего не забыл. Поправьте, если что не так.
Ну вот поправил. Не похоже, чтобы в этой теме можно было разобраться в формате обмена комментариями. Или мне нужно было написать всё обстоятельно, ответить на вопросы, а потом поправить и дополнить написанное. Или вам лазить по комментам и ссылкам, пытаясь собрать всё воедино.
> [1] http://www.washingtonpost.com/sf/business/2015/11/05/net-of-.../
> [2] https://grsecurity.net/rap_faq.php
> [3] https://www.linux.com/news/google-developer-kees-cook-detail...
> [4] https://lwn.net/Articles/705262/
> [5] https://grsecurity.net/~spender/pics/grsecurity_pax-influenc...
Этих ссылок явно недостаточно для понимания ситуации в целом, даже в сумме с выше сказанным. Вернее, для формулирования содержательного и обоснованного собственного мнения (независимо от конкретного его содержания). Но вряд ли есть смысл и продолжать. Тем более, что кроме нас двоих, комментарии вряд ли кто-то не читает. Возможно также, что когда эта тема в очередной раз всплывёт, объяснять некоторые вещи уже не понадобится.
