https://www.opennet.ru/openforum/vsluhforumID3/111099.html Проект grsecurity объявил (https://grsecurity.net/passing_the_baton.php) о прекращении бесплатного распространения своих патчей c реализацией надстроек для усиления безопасности ядра Linux. Если с августа 2015 года было прекращено (https://www.opennet.ru/opennews/art.shtml?num=42856) распространение стабильных версий патчей, то отныне прекращается и публикация находящихся в разработке экспериментальных веток. Прямой доступ к патчам смогут получить только платные подписчики Grsecurity. При этом сами патчи продолжают распространяться под лицензией GPLv2, т.е. получив код от Grsecurity платные подписчики вольны распространять (https://github.com/slashbeast/grsecurity-scrape) и модифицировать патчи.<br><br><br><br><br>Последним общедоступным выпуском (https://grsecurity.net/download.php) станет набор патчей для ядра 4.9.Патчи для более свежих выпусков будут развиваться за закрытыми дверями в рамках внутренней ветки, доступ к которой будет ограничен, но платным подписчикам могут быть предоставлены бета-версии. Сообщается, https://www.opennet.ru/openforum/vsluhforumID3/111099.html#193 Fri, 12 May 2017 23:34:52 GMT &gt; На первый взгляд обе уязвимости относятся к race condition. Чтобы <br>&gt; такое выловить надо найти код, выполнение которого зависит от данных, которые <br>&gt; можно изменить кодом в другом потоке. То есть надо построить некую <br>&gt; карту покрытия кода и данных разными потоками и найти, где они <br>&gt; пересекаются, когда работают параллельно.<br><br>Я (также будучи дилетантом) мыслю в том же направлении: построить модель, определить "проблемные места" и попытаться с ними "что-то сделать", применяя различные формы обратной связи в поиске вариантов решений, оценке результатов и для уточнения модели. Беда в том, что, в частности, проблема взаимодействия через семафоры (блокировки по коду и данным) более чем трёх процессов является математически неразрешимой. Поэтому результаты любого моделирования ситуаций гонки с количеством процессов больше двух в принципе будут неполны и не дадут никаких строгих гарантий для защищающейся стороны, но при этом в принципе способны полностью удовлетворять нужды атакующей стороны: выявлять некото https://www.opennet.ru/openforum/vsluhforumID3/111099.html#192 Fri, 12 May 2017 02:18:04 GMT Немного отвлекаясь от основной темы ("что делать чтобы исправить ситуацию")...<br><br>&gt; вспомните последние наиболее серьёзные уязвимости: CVE-2014-3153 и CVE-2016-5195. Grsecurity никак не уменьшает сложность их эксплуатации.<br><br>А как можно помешать эксплуатации подобных уязвимостей? Или, ещё лучше, выловить подобные места на этапе компиляции? (мысли дилетанта вслух, прошу не судить слишком строго) На первый взгляд обе уязвимости относятся к race condition. Чтобы такое выловить надо найти код, выполнение которого зависит от данных, которые можно изменить кодом в другом потоке. То есть надо построить некую карту покрытия кода и данных разными потоками и найти, где они пересекаются, когда работают параллельно. Grsecurity уже пытается строить карту допустимых вызовов в рамках RAP-а, может её можно расширить и на race conditions?<br> https://www.opennet.ru/openforum/vsluhforumID3/111099.html#191 Thu, 11 May 2017 06:07:35 GMT В коллекцию ссылок. Свежее письмо от PaX Team: http://www.openwall.com/lists/kernel-hardening/2017/05/11/2<br> https://www.opennet.ru/openforum/vsluhforumID3/111099.html#190 Wed, 10 May 2017 03:12:47 GMT &gt;&gt; UDEREF для x86 (не x86_64) на базе механизма сегментации памяти.<br>&gt; Это тот, где адресное пространство делится на два куска по полтора гига? <br><br>Нет, этот тот, для реализации которого всего-навсего используется сегментация, без наложения каких-либо ограничений на количество адресуемой памяти. Реализация UDEREF для x86 - самя быстрая, самая надёжная и бесплатная в плане производительности. Но вот не место сегментации в ядре, по мнению Торвальдса, и всё тут.<br><br>Лимит в полтора гига был у SEGMEXEC, который нужен был для реализации W^X на старых процессорах без поддержки NX-бита. К тому же, SEGMEXEC легко отключается для отдельно взятого исполняемого файла посредством его пометки соответствующим PaX-флагом (маленькая s) или непометки (большая S) в случае soft mode. Но зачем пользователям возможность выбора, правильно? ;)<br><br>&gt; Мне та идея тоже не очень нравилась, в наше время полтора <br>&gt; гига для одной программы &#8212; не так и много.<br><br>Торвальдс высказался в адрес сегментации как таковой и сделал это отнюдь не https://www.opennet.ru/openforum/vsluhforumID3/111099.html#189 Tue, 09 May 2017 17:42:39 GMT &gt; Есть и относительно небольшие имзменения, которые апстрим не принимает в принципе - потому что они ему не нравятся, буквально. Торвальдс, в частности, негативно высказывался в адрес реализации UDEREF для x86 (не x86_64) на базе механизма сегментации памяти.<br><br>Это тот, где адресное пространство делится на два куска по полтора гига? Мне та идея тоже не очень нравилась, в наше время полтора гига для одной программы &#8212; не так и много.<br><br>&gt; Похоже, мне так и не удалось донести мысль... Сообщество уже страдает [...] Представте, что нет Grsecurity, вообще, и аналогов тоже. Но есть плачевная ситуация с безопасностью ядра, есть KSPP (или аналогичная инициатива) с его эрзац-результатами, годными только в качестве основы для лживого пиара, и есть LF, собственно, трубящая в уши пользователей о великих успехах KSPP.<br><br>Да, я понимаю. Но как раз эту ситуацию закрытие патчей только ухудшает. Навешивание лапши на уши это не остановит &#8212; существующих идей и патчей хватит ещё не на один год портирования и пиара. Но https://www.opennet.ru/openforum/vsluhforumID3/111099.html#188 Wed, 03 May 2017 19:04:33 GMT &gt; Но цель же не в том, чтобы дрессировать апстрим принимать объёмные изменения.<br>&gt; Цель &#8212; получить хорошо защищённое ядро.<br><br>Чтобы получить действительно хорошо защищённое ядро, в его код нужно вносить системные изменения, которые бывают довольно объёмными и/или инвазивными, иногда затрагивая весь код ядра. Например, REFCOUNT, CONSTIFY и, конечно же, RAP. Такие изменения на данный момент либо не принимаются вовсе, либо принимаются в урезанном виде и только так, без реальных перспектив расширения их области применения, хотя бы, до той, которая уже достигнута в grsec.<br><br>Есть и относительно небольшие имзменения, которые апстрим не принимает в принципе - потому что они ему не нравятся, буквально. Торвальдс, в частности, негативно высказывался в адрес реализации UDEREF для x86 (не x86_64) на базе механизма сегментации памяти. Та же судьба ожидает per-cpu PGD, необходимые для реализации UDEREF на x86_64, как и сам принцип ремаппинга пользовательских страниц при каждой смене контекста/режима: будет сказано, ч https://www.opennet.ru/openforum/vsluhforumID3/111099.html#187 Wed, 03 May 2017 15:49:31 GMT &gt; Ага. Так отмер, что даже циска уже на линуксах системы строит, и <br>&gt; давно.<br><br>И много с того линукса досталось сообществу? На асиках всё вертят плюс к этому возможность зативоизировать. Опенсорс, каким он представялся лично мне 10 лет назад, помер.<br> https://www.opennet.ru/openforum/vsluhforumID3/111099.html#186 Wed, 03 May 2017 00:54:57 GMT &gt; Это очень важное и очень сильное допущение, что с каждым изменением ситуация будет улучшаться. [...] Зачем или почему вдруг апстрим станет менять приоритеты и подход, пропускать в ядро более объёмные и сложные изменения?<br><br>Но цель же не в том, чтобы дрессировать апстрим принимать объёмные изменения. Цель &#8212; получить хорошо защищённое ядро. И не настолько важно, как мы к нему придём. Конечно, было бы хорошо получить его сразу, за один шаг, но если апстрим не хочет больших шагов, можно же попытаться достичь той же цели маленькими шажками? Даже если это будут неполные, половинчатые патчи &#8212; это не так страшно, если в конце из всех этих половинок будет собрано то самое защищённое ядро, которое и было целью.<br><br>К тому же нужно ведь не только передать эти патчи в ядро, нужно чтобы другие разработчики тоже в них разобрались, и привыкли писать последующий код с учётом этих патчей. Грубо говоря, нужно обучить и других разработчиков. И делать это на маленьких патчах проще, чем на больших.<br><br>&gt; Мне кажется, https://www.opennet.ru/openforum/vsluhforumID3/111099.html#185 Tue, 02 May 2017 17:37:01 GMT Ага. Так отмер, что даже циска уже на линуксах системы строит, и давно.<br>