> Меня тут уже поправили, я чего-то стормозил: достаточно подписывать файлы сумм. Но
> это таки обозначает шифрование. Подписывание = шифрование закрытым ключом. Проверка =
> расшифровка открытым ключом. Так что исходный тезис остаётся в силе. А*facepalm* Тезис о необходимости двух комлпектов файлов? С ним уже разобрались. Остальное - игра в слова вне изначального контекста.
> иметь образы, которые не делают проверку — это половинчатое решение. Из
Повторяю: ничто не мешает реализовать проверку подписей в инсталляторе для сидюков. И кстати, целостность этих образов пользователь тоже должен будет проверять самостоятельно.
> разряда «с вероятностью 1/10 данный сервис будет запущен с правами рута».
> Это как раз и будет видимость защиты.
Ничего вероятностного в проверке подписей нет: они или совпадут, или нет.
> Можно сказать и так, про приоритеты.
Да. Но вместо этого они рассказывают о сложностях, об иллюзорности защиты с помощью ЭЦП (подменяют наличие рисков иллюзорностью защиты вообще) и вместе с тем о незначительности этих рисков, связанных с подменой файлов, предлагая негодные решения для их минимизации (вроде сопоставления файлов с нескольких зеркал).
> В основном они касаются рандомизации (много как источников, так и потребителей случайных
> данных), ну и стандартно включённые в GCC механизмы. Тот же
То есть, ничего существенного (за исключением недавнего запрета на маппинг нулевого адреса). Ядро - очень сложная программа с массой внешних интерфейсов, в которых априори есть уязвимости к утечкам ифнормации, включая рандомизированные значения. Нельзя считать рандомизацию (которая там, допустим, есть ещё где-то, кроме как на стеке) сколько-нибудь достаточной мерой. Сомневаетесь - спросите мнения экспертов на Full-Disclosure.
Уязвимость в IPv6 помните? Выполнение кода в области данных, внутриядерным аналогом W^X предотвращается на раз. При этом CORE Security предложили реализовать именно такую защиту (в т.ч. для x86). И где же пресловутый проактивный подход к обеспечению безопасности в OpenBSD? Вопрос риторический, ибо даже с реактивным запаздывают.
> ProPolice в OpenBSD включён по дефолту, и сейчас перепроверил — при
> сборке ядра -fno-stack-protector не используется.
А если он в спецификациях GCC указан? Лучше посмотрите в дизассемблере код функций перед возвратом.
> Излагает своё видение, только и всего. Иногда сны, это просто сны. ;)
Это "видение" вводит читателей в заблуждение. Вот пара выводов оттуда:
1. Для проверки целостности установочных файлов достаточно получить их с нескольких надёжных зеркал и удостовериться, что содержимое одинаково.
2. Аудит кода усложняет эксплуатацию (а не поиск) уязвимостей в ядре.
Почему эти выводы ложные, я уже объяснил.
> Теорию заговоров оставьте тем, кого хватает лишь на переложение Умберто Эко.
> :)
Не доводите до абсурда. Выдавать желаемое за действительное можно по многим причинам.
> Хм. Не совсем понял, что здесь не так? Утверждение, что нет ни
> одной абсолютно безопасной системы? :)
Я уже сказал, что не так: игра слов вокруг integer overflow, которые в Си и в джаве совершенно разные по семантике (в джаве нет мутабельных указателей на произвольные адреса, есть только индексы).
> Это вы домыслили, что их (переполнения) напрямую можно для этого использовать. Так
Конечно я домыслил - смысловой контекст к этому и подводит.
> что кто ещё занимается подменой понятий. ;) Если хотите узнать, что
Хватит юлить. Термин "integer overflow" дан в контексте, который способствует неверному толкованию.
> стояло за этими словами, надо бы спросить аффтара. Это ж всё-таки
> только презентация, без расшифровки речи её ведущего. Насколько я понимаю идею,
Слайдом раньше этот искренний и непредвзятый автор предложил погуглить "java vulnerability", чем и подготовил контекст для термина "integer overflow". Можно, конечно, предположить, что на словах он выразил суть более чётко и ясно. Кстати, в случае с "java vulnerability" снова подмена понятий: были смешаны джава как платформа и джава как язык - то есть без уточнений.
> путём провоцирования переполнений можно как минимум вызвать удалённый DoS...
Даже DoS далеко не во всех случаях. В джаве можно ловить исключения.
> Так смысл в не в том, что «Java — суксь», а в
> том, что она не есть панацея.
Смыслов тут может быть больше одного - риторика в слайдах оставляет выводы на совести зрителей.
> OpenBSD их не использует по ряду причин как технического, так и нетехнического
При наличии нетехнических причин, технические очень легко надумать: ой нестабильность, ой низкая производительность, ой непортабельность. И главное, априори.
А на деле... Код на типобезопасных языках гораздо более стабилен, особенно если писать его так же аккуратно. На типобезопасных языках написаны высоконадёжные системы такой сложности, рядом с которой OpenBSD со всеми потрохами и рядом не валялась.
То же самое с производительностью. Эти люди дробят приложения на непривилегированные процессы, увеличивая число переключения контекстов и циклов сериализации/десериализации для обмена данными между процессами только ради того, чтобы подпереть костылём небезопасные типы в Си.
То же самое с надуманной непериносимостью, как будто Си тут непревзойдён. Пляски вокруг выравнивания структур, endianess, размеров буферов в динамической памяти и разных размеров значений типов на разных платформах - это переносимость? Не смешно.
> характера. Это где-то в списках рассылки мелькало... Суть аргументов опёнковцев сводится
> к тому, что: 1. На Си _можно_ писать удобочитаемый безопасный код,
Нельзя на Си писать такой код.
> и при этом остаётся доступной его несравненная гибкость и нетребовательность к
> ресурсам; 2. Компиляторы C, по крайней мере некоторые, на порядок надёжнее
Что вы понимаете под несравненной гибкостью? И в сравнении с чем, по-вашему, она несравненна? Даже если спорить на эту тему не хотите, просто дайте ответ - мне интересно для личной статистики.
> компиляторов С++ (это к вопросу о плавной миграции), не говоря о
> D и иже с ним; 3. Портабельность как одна из основных
Вот так вот: и иже с ним. То есть, пилить собственный доисторический PCC, плетясь далеко позади GCC в плане оптимизации кода - это как по-вашему, надёжнее, проще, эффективнее, производительнее? Вы хотя бы отдаёте себе отчёт, что проще написать оптимизирующий компилятор для типобезопасного, статически типизированного языка, нежели для Си или С++?
> идей фактически вынуждает к использованию Си — потому что код на
Интересно получается: других не вынуждает, а разработчиков OpenBSD фактически вынуждает. Я думаю, отсутствие заинтересованности тут не следствие, а причина.
> Си уже есть и работает, а тот же какой-нибудь Оберон _и_все_необходимые_библиотеки_
> портировать на кучу платформ... «сам топи урановые ломы в ртути» ©
> BOR. :)
Какой-нибудь оберон, как и другие языки, можно транслировать в Си и собирать любым доступным компилятором. Вы как-то очень избирательно комментируете.
> Типобезопасное ядро? Это возможно, конечно. Только кто им будет пользоваться, если оно
> будет при этом нещадно тормозить по сравнению с конкурентами? А оно
> будет.
Это сейчас ядро, написанное на Си, нещадно тормозит по сравнению с конкурентами, потому что мутабельные структуры данных облепили совместным доступом с блокировками, и совершенствовать это чудо научно-технической мысли и венец гибкости языка Си с оглядкой на реалии почему-то вдруг стало сложно.
> А так — разработчики и Perl не брезгуют (pkg_*), и шелл-скриптингом (sysmerge
> и ещё один сюрприз, который будет в новом отчёте)... они, правда,
Ещё бы они брезговали: старый, привычный ширпотреб - учиться самим и учить других ничему новому не надо.
> Так что Си — это просто данность, да. И опёнковцы сделали немало,
> чтобы эту данность максимально улучшить. По крайней мере, уязвимостей во всей
> системе находят меньше, чем в том же OpenJDK. ;)
Вы хотя бы понимаете, что в процессе аудита и корректирования кода многие уязвимости правятся без огласки и осознания их статуса? В деталях вы сами себе противоречите и путаетесь в понятиях: исправляют, находят, публикуют.
> Значит, у вас всё в порядке, как я понимаю. :) Чему, собственно,
> искренне рад.
Что вы, порядок нам только снится. На практике в силу разных причин приходится применять костыли, ширпотреб, убогое наследие предков и прочий срам.
