>[оверквотинг удален]
>> в общем случае это не даёт ничего.
> Про то и речь. Только с уточнением результата - для AMD64 нормально
> работает.
>> И в чём смысл издёвки? Дать собеседнику понять, что он зря тратит
>> время на троллей? По UDEREF для x86 есть документация на pax.grsecurity.net,
>> по UDEREF для amd64 есть вводная в архивах рассылки Grsecurity. Плюс
>> хелп в конфигураторе ядра для большинства механизмов защиты. Если интересно, изучайте
>> - я для того все названия и привожу.
> В смысле архитектурно linux и freebsd отличаются. Настолько, что copyin/copyout - я
> уж и не припомню когда появились для freebsd. Я про то,Да нет там никаких принципиальных различий, разница по сути в мелочах.
> что изначально не было разыменования user указателей для ядра.
Публично о классе этих уязвимостей начали говорить где-то с 2003 года. А уязвимости были изначально (и кстати эксплуатировались втихую до первых публикаций), спасала от них разве что сегментация (как раз на x86), и с функциями копирования в/из юзерспейса они никак не связаны.
> Изначально при использованиии copyin/copyout использовались проверки границ.
И в чём ваша мысль?
> Троллинг может и имеет тут место, поскольку подозреваю, что в линуксе обязано
> было существовать подобное. Делаю выводы - видимо я не понял, про
Так и не понял, зачем или почему троллинг. Проехали.
> что шла речь. И хотя я походил по ссылкам через гугл-поводырь,
> но утомленные глаза уже щурятся от такого количества инородных букв. Если
> можно, коротко, от чего защищают UDEREF и USERCOPY? Например, если на
> пальцах?
Процитирую отсюда:
http://www.grsecurity.net/~spender/uderef.txt
many kernel bugs can be exploited (at all
or more reliably) due to the fact that on i386 most OSs don't separate
the userland virtual address space from that of the kernel. this in
turn means that whenever userland can make the kernel (unexpectedly)
dereference a userland controlled pointer, userland can control the
data (and sometimes, control) flow of the kernel by virtue of providing
the attack data in its own userland address range as it's fully visible
in the kernel's virtual address space as well (the two virtual address
spaces are the same because of the use of flat segments and lack of
effective address space IDs in the i386 paging logic).
В amd64 и многих других архитектурах сегментация отсутствует, так что оговорки про flat segments можно пропустить.
Реализация UDEREF вкратце описана здесь: http://grsecurity.net/pipermail/grsecurity/2010-April/001024...
Суть та же: не дать ядру случайно использовать данные, которые потенциальный злоумышелнник мог сформировать специально для вредоносного изменения хода выполнения кода в ядре.
По USERCOPY взято отсюда: http://grsecurity.net/news.php#develup
PAX_USERCOPY: this feature I developed (which was improved and added within PaX) performs bounds checking on kernel objects, when copying into or out of them via userland. The feature provides the most protection for objects located on the heap (the feature supports all current allocators: SLAB, SLUB, and SLOB, with the strictest checks existing for SLUB). For objects located on the stack, the bounds checking is less strict -- mainly to prevent infoleaking of the entire kernel's memory space. The bounds checking on stack objects will improve in future versions of the feature.
> Да, но проценты имеют свойство множиться друг на друга. И кстати, да
> - может именно 0.5%-2.0% - тут моя память есть очень непольшой.
Ну вот, опять общие рассуждения. Там O(1), между прочим. И пока вы рассуждаете, у многих всё это работает, защищает от атак и не множится. Вот опять-таки к слову: на серьёзных объектах (местная краевая администрация) я наблюдал компрометацию FreeBSD 3.5.х и 4.х аж в 2001-ом или даже 2000-ом году. И с розовым взглядом неуловимого джо на мир расстался тогда же. И повезло ещё, что наследили - а то бы не и расстался.
> Ага, это видел, правда сам не включал/не выключал.
Но суть-то в том, что в линуксе выбор между SSP и её отсутствием есть уже давно, а во FreeBSD его практически не было. И пригодность её для решения отдельно взятых задач от этого тоже страдала.
> Я - упертый фрибээздятник. Там gdb - 6.1.1, а вместо paxctl -
> отсутствие этого самого PaX.
Ну так получается, что проблемы самой FreeBSD вы объявляете общими и будто бы даже практически нерешаемыми. Включить в систему gdb 7.x или собирать его из портов кто мешает? А реализовать гибкое и простое управления механизмами защиты, как в PaX? Никто не машает. У разработчиков FreeBSD просто другие приоритеты. И вот что важно: публично они эти моменты нигде не разъясняют и тем самым косвенно вводят своих пользователей в заблуждение.
> Еще раз, давайте про UDEREF и USERCOPY - что началось, где началось
> - чего они делают то в конце концов. Ссылка наверняка на
> русском есть. Почему не на английском? Можно и на английском, только
> не список рассылки или доски объявления, где вы как дома и
> знаете, что где. Мне linux от обилия только вам понятных слов
> интересней не станет (думаю, как и другим).
Выше дал цитаты и ссылки на нормальные объяснения.
>> Линукс уже работает на большем количестве платформ, и это не мешает ему
>> служить для эффективного решения других задач. Тоже к слову.
> Ну с NetBSD все равно не сравнится. Тоже к слову.
Я слышал другое авторитетное (для меня) мнение. Впрочем, важно другое: вся ваша классификация BSD неверна по сути и по форме.
> А кто спорит?
Не знаю, кто спорит, но ваше "тождество" между DragonFly BSD и кластеризацией притянуто за уши и не учитывает экспериментального характера ОС - какие тут кластеры в продакшене?
> Ну это вы зря. Продакшены тоже разные бывают. Там, где ОС не
Ну вот, теперь вы перешли от общего случая к частному: уже не для продакшена (вообще), а для отдельно взятого. О том и речь.
> корябают им стол. Но все равно, спроси, почему одним нравится один
> дистрибьютив линукса, чем другой - внятного ответа не дождешся. Ну разве
> что slackware - их позиция будет понятна.
Ну раз уж зашла речь: я, например, могу чётко обосновать свой выбор, критерии и факты, на основании которых я выбрал или забраковал тот или иной дистрибутив (не важно, какой ОС) для решения той или иной задачи.
>>> И вообще, считается, что защита связанная с усложнением технологии по преодолению защиты
>> Любой принцип можно довести до абсурда, игнорируя даже чёткие доводы и наглядные
>> примеры. Случай с безопасностью во FreeBSD как раз такой. Там просто
>> гонятся за производительностью и функционалом, а положение неуловимых джо позволяет говорить
>> и делать глупости.
> Почему же так резко прервались? Давайте уж тогда я продолжу: "...и простотой
> кода, который можно поддерживать относительно небольшим коллективом распределенных разработчиков.
"Прервался" потому, что всё сказал.
PaX - набор сторонних патчей на постоянно развивающееся ядро, количество разработчиков - ОДИН. Grsecurity - тоже набор патчей на то же ядро, количество разработчиков - ОДИН. Итого ДВА человека успевают вовремя и качественно адаптировать и дополнять свои патчи на изменчивую и неподконтрольную им кодовую базу. Качество кода можете оценить сами:
http://www.grsecurity.net/~spender/grsecurity-2.2.0-2.6.35.7...
> Ясность является дополнительной степенью защиты от закладок в коде"
И ясность тоже можете оценить. А о закладках - зачем они нужны, когда проще потратить меньшие деньги с меньшими рисками на поиск уязвимостей, от которых ядро FreeBSD никак не защищено?
> Указатели на юзерспейс? Из ядра? Ахтунг! Ахтунг! Альарм! Альарм! Надо подымать великого
> Ктулху, ибо девел не справился! Все идет к тому, как я
> понимаю, что в линукс указатели на юзерспейс на кольце ядра выполняются(выполнялись)?
> Теперь у меня есть один аргумент - почему не linux :)
Шутки - шутками, но вот со стороны очень похоже, что ко многим, если не всем, высказанным здесь выводам вы пришли очень похожими рассуждениями. Для справки: уязвимости к обращению (термин "разыменование" мне не нравится) по нулевому указателю - частный случай уязвимости к обращению по указателю на юзерспейс. Для (а лучше до) просветления советую погуглить FreeBSD null pointer dereference vulnerability.
> Свободная файловая система, которая многими своими свойствами импонирует структуре ОС
> и её лицензии - зарекомендовала себя только так уже при первом
> приближении.
Итак, глыба нестабильного, нарушающего каноны, кода ZFS была включена в ядро FreeBSD из соображений расширения функционала. Как-то это плохо стыкуется с вашей аргументацией против реализации механизмов защиты. ;)
> Не путайте профессионалов и мега-супер-универсалов-хатха-йоги-хари-кришна.
Я думаю, что не путаю.
