>> На "статистику по дырам" ориентироваться бессмысленно, т.к. в первую очередь на неё
>> влияет популярность данной ОС и желание отдельных людей и организаций заниматься
>> поиском уязвимостей данной ОС.
> Я про это и говорю. Зачем городить огород раньше времени,
> если по факту дыры
> либо никто не ищет, либо они закрываются другими методами(например чистотой кода).Вы говорите совершенно об обратном и вдобавок питаете иллюзии о чистоте кода, которой нет.
Для получения инструмента компрометации ядра FreeBSD человеку нужно:
1. Найти уязвимость, поддающуюся эксплуатации.
2. Написать эксплойт.
3. Держать уязвимость в секрете.
История опубликованных уязвимостей ядра FreeBSD показывает, что находить их под силу отдельным людям (гуглите FreeBSD kernel vulnerability и смотрите авторство). Этим же (равно как и другим) людям по силам писать PoC-эксплойты (FreeBSD root exploit в гугле), поскольку эксплуатация весьма прямолинейна и не требует обхода механизмов предотвращения (которых просто нет). Разница между злоумышленником-одиночкой, обладающим достаточными знаниями и навыками, и таким исследователем-одиночкой лишь в планах, мотивах и действиях по п.3.
В случае линукс-ядер с PaX и Grsecurity преодолеть п.1 и п.2 становится значительно сложнее, т.к. сужается перечень "полезных" ошибок под действием механизмов защиты, исключающих целые классы уязвимостей и методы их эксплуатации. Например, UDEREF не позволяет ядру обращаться по указателям на юзерспейс. KERNEXEC реализует W^X для пространства ядра и блокирует запись во многие уязвимые структуры данных (не кода), MEMORY_SANITIZE предотвращает утечки данных, обнуляя всю память, выделяемую в юзерспейс, и так далее.
Поэтому на практике абсолютное большинство ошибок либо не поддаётся эксплуатации (в разумные сроки и за разумную цену), либо требует создания сложных многоходовых эксплойтов.
К тому же:
1. Уязвимостями торгуют и делятся в приватных кругах.
2. Одна и та же пара уязвимость+эксплойт может быть использована многократно для атаки на множество независимых целей разными людьми (так обычно и происходит).
3. Не обольщайтесь, если полагаете, будто компрометация отдельно взятых ваших машин обойдётся кому-то в совокупную стоимость поиска уязвимости и написания боевого эксплойта (в случае локальной эскалации привилегий от PoC он не отличается ничем) - кто-то знакомый может подарить взломщику интсрументарий за "спасибо, сочтёмся" или в обмен на информацию.
4. Уязвимость можно обнаружить, просто случайно порушив систему в процессе работы или читая чужие (!) баг-репорты в трекере.
5. Почти всё сказанное применимо к уязвимостям во многих сетевых демонах, а чаще уязвимые веб-приложения и вовсе упрощают проникновение.
Лично я считаю, что игнорировать такую ситуацию целесообразно, лишь когда защищать по большему счёту нечего.
> Все эти механизмы выглядят скорее костылями.
Вопрос в том, насколько приемлема ситуация при отказе от таких костылей.
>>Есть другие ориентиры: типобезопасность языка,
> С этим хорошо пожалуй только в линейке модула/оберон(из тех о чем слышал
> я)
Много, где хорошо. Даже в яве.
>>наличие в команде разработчиков активных экспертов по безопасности,
> имеются
И кто они?
>> влияние модели разработки на ситуацию с безопасностью
> соборная модель выглядит предпочтительнее базарной с этой точки зрения.
Слишком общее суждение. Я другое имел ввиду. Посмотрите, как в OpenBSD: перед включением кода в основную ветку его обязательно проверяют ещё один или несколько разработчиков. Приоритеты и требования: корректность, простота, безопасность. В линуксе с этим туго, как во FreeBSD - не знаю.
>> сама политика реагирования на инциденты, связанные с безопасностью и т.д.
> обычная политика. дыры латаются быстро, выпускается отдельный патч.
Не бывает обычных политик, а перечень возможных реакций и решений выпуском патчей не исчерпывается. Кто-то стремится устранить причины доступными средствами, а кто-то - вечный реакционер.
> Может. Модель разработки и институтские корни. Я больше доверяю экспертам
> от
> науки.
Риски вы тоже на основании доверия "экспертам от науки" рассчитываете? Наука давно ушла вперёд и адекватна сегодняшней действительности, а мы по-прежнему привязаны к сорокалетнему наследию сомнительного качества двух инженеров из AT&T. Жаль, что об оберонах вы всего лишь слышали.
