> В плане, невнимания к защите ядра? Сначала разработали технологию, потом начали внедрять.
> Тот же SSP в ядре появился тогда, в 2003: Это всего лишь защита от линейных переполнений, которая на тот момент была (а может и до сих пор) ослаблена постоянным canary-значенем, которое не менялось при обработке системных вызовов - одна утечка, и защиты нет.
> Поясните, что вы подразумеваете под защитой ядра? И в чём конкретно претензия?
Под защитой ядра я подразумеваю наличие механизмов защиты ядра от эксплуатации различных классов уязвимостей. Наличие ослабленной SSP от линейных переполнений на стеке - это недоразумение и абсолютно ничего существенного (что, кстати, доказывается бесполезностью SSP для защиты от впоследствии опубликованных уязвимостей).
> В конкретно отмеченном мною случае более поверхностным _местами_ показал себя именно этот
> эксперт.
Если бы он допустил технический ляп, я бы с вами согласился. Но в данном случае вы пытаетесь выдать за ошибку разницу между его и вашим мнением.
> Погодите, погодите. Эффект любой защиты в конкретной ситуации может быть нивелирован брешью
Именно. Но сейчас ваши доводы звучат, как оправдание закрепление мощной лобовой брони танка несколькими болтами на алюминиевый каркасс. Попадание снаряда может не пробить броню, но танк раскурочит наверняка. Компренде?
Разделение привилегий (а также различные jail'ы и MAC-системы) и защита ядра являются звеньями одной цепи, прочность которой равна прочности самого слабого звена.
С отзывом привилегий (privilege revocation) дело обстоит иначе: если процессу, допустим, запрещено использовать некий системный вызов либо целиком, либо с неким набором аргументов, обработкой которых занимается некий уязвимый код, то такой запрет выполнит задачу по предотвращению эксплуатации уязвимостей в отдельных участках кода (тот же эффект достигается за счёт выкидывания из ядра лишнего кода тем или иным способом). Это, насколько я могу судить, и имел ввиду PaX Team, говоря о бесполезности privilege separation (в свете незащищённого ядра) и полезности privilege revocation (как раз для защиты такого ядра).
Почему для вас это не очевидно? Возможно, у вас ещё остались иллюзии о безопасности ядра, код которого пишется "с безопасностью в уме" и якобы проходит постоянный аудит. У меня, после публикации уязвимости в коде IPv6 и локальных root-уязвимостей по причине банального NULL pointer dereference, таких иллюзий не осталось. А у PaX Team их не было уже на тот момент. Что кагбе говорит о его низкой квалификации, да. ;)
> "на соседнем участке". Это действительно, понятно даже ёжику. Но по вашей
Это заблуждение, которое различным ёжиком привили люди, вроде Бернштейна и разработчиков OpenBSD, отвлекая внимание от проблемы самого слабого звена. Которая, казалось бы, тем же ёжикам вполне известна и нередко цитируюется. Но, вот, есть какие-то трудности с тем, чтобы сложить 2 и 2.
> логике, получается, вообще ничего делать не надо, если только не всё
По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или наоборот.
> сразу? Была произведена подмена темы, вы разве не видите? Вместо защитного
Не вижу. Обсуждаем звенья одной цепи.
> механизма речь зашла о совсем другом участке кода. Из серии: "Ну
> и что, что 4x4, всё равно задних сидений нет". Это был
> банальный софизм, а вы его ещё и защищаете почему-то.
Этот "софизм" совпадает с моими собственными выводами.
> Не лично, прошу заметить. ;)
В смысле? Лично за наградой не явился? ;)
