>> В плане, невнимания к защите ядра? Сначала разработали технологию, потом начали внедрять.
>> Тот же SSP в ядре появился тогда, в 2003:
> Это всего лишь защита от линейных переполнений, которая на тот момент была
> (а может и до сих пор) ослаблена постоянным canary-значенем, которое не
> менялось при обработке системных вызовов - одна утечка, и защиты нет.

Проверил сейчас GCC в базе, канарейка генерится уникальная для каждой функции на базе адреса этой самой функции. Значение между вызовами не меняется:

1c0007aa:       a1 40 31 00 3c          mov    0x3c003140,%eax
1c0007af:       89 45 fc                mov    %eax,0xfffffffc(%ebp)
1c0007b2:       31 c0                   xor    %eax,%eax
<...>
1c0007ce:       8b 55 fc                mov    0xfffffffc(%ebp),%edx
1c0007d1:       33 15 40 31 00 3c       xor    0x3c003140,%edx
1c0007d7:       74 0c                   je     1c0007e5 <cantest+0x41>
1c0007d9:       c7 04 24 1c 00 00 3c    movl   $0x3c00001c,(%esp)
1c0007e0:       e8 17 fd ff ff          call   1c0004fc <__init+0x2c>

Если ядро выполняется стоковое, то, получается, наличие и значение канарейки злоумышленнику будет известно. Хреново. Если не стоковое, то нужна не просто утечка, а из данного системного вызова. Две разных уязвимости на один системный вызов - гм-м-м... Теоретически возможно, конечно. Но учитывая, что между вызывающим потоком выполнения и собственно кодом обработчика системного вызова стоит диспетчер, я слабо представляю себе способ добраться до нужного системного вызова.

В вашем ненаглядном PaX, как я понимаю, дела обстоят лучше? Что там генерится?

>> Поясните, что вы подразумеваете под защитой ядра? И в чём конкретно претензия?
> Под защитой ядра я подразумеваю наличие механизмов защиты ядра от эксплуатации различных
> классов уязвимостей. Наличие ослабленной SSP от линейных переполнений на стеке -
> это недоразумение и абсолютно ничего существенного (что, кстати, доказывается бесполезностью
> SSP для защиты от впоследствии опубликованных уязвимостей).

А какие уязвимости, по-вашему, были бы невозможны к эксплуатации за счёт имеющихся в том же PaX технологий?

>> В конкретно отмеченном мною случае более поверхностным _местами_ показал себя именно этот
>> эксперт.
> Если бы он допустил технический ляп, я бы с вами согласился. Но
> в данном случае вы пытаетесь выдать за ошибку разницу между его
> и вашим мнением.

Ошибка (не столько техническая - назвать страуса павлином, - сколько логическая, да) в том, что он прямо говорит: "разделение привилегий бесполезно, так как неуязвимых ядер не бывает". Простите, но это бред. Вы сами ниже пишете, что, мол, "По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или наоборот". Вот, одну вещь сделали. Ваша (или, по крайней мере, товарища Альбертса) претензия в том, что это не произошло одновременно? Ну извините. Может, PaX/GrSecurity тоже за ночь появились? Или напомнить об уязвимостях в самих этих защитных механизмах? Я не User294 и кричать epic fail по этому поводу не собираюсь, косяки у всех бывают. Но как-то думать над тем, что пишешь, тоже надо. Ну или отвечать за свои слова.

Я не пойму, что вы покрываете автора текста, он вам денег должен? :)

>> Погодите, погодите. Эффект любой защиты в конкретной ситуации может быть нивелирован брешью
> Именно. Но сейчас ваши доводы звучат, как оправдание закрепление мощной лобовой брони
> танка несколькими болтами на алюминиевый каркасс. Попадание снаряда может не пробить
> броню, но танк раскурочит наверняка. Компренде?
> Разделение привилегий (а также различные jail'ы и MAC-системы) и защита ядра являются
> звеньями одной цепи, прочность которой равна прочности самого слабого звена.

Спасибо, кэп.

> С отзывом привилегий (privilege revocation) дело обстоит иначе: если процессу, допустим,
> запрещено использовать некий системный вызов либо целиком, либо с неким набором
> аргументов, обработкой которых занимается некий уязвимый код, то такой запрет выполнит
> задачу по предотвращению эксплуатации уязвимостей в отдельных участках кода (тот же
> эффект достигается за счёт выкидывания из ядра лишнего кода тем или
> иным способом). Это, насколько я могу судить, и имел ввиду PaX
> Team, говоря о бесполезности privilege separation (в свете незащищённого ядра) и
> полезности privilege revocation (как раз для защиты такого ядра).

Я не люблю строить догадки, кто что имел в виду. Есть конкретные слова: "privilege revocation does actually make sense however privilege separation (not seperation) doesn't. for noone has a bugfree kernel". Если он хотел сказать что-то другое - сочувствую, конечно, но подтверждений этому не вижу.

> Почему для вас это не очевидно? Возможно, у вас ещё остались иллюзии
> о безопасности ядра, код которого пишется "с безопасностью в уме" и
> якобы проходит постоянный аудит.

Я смотрю на количество errata в ядре Linux и ядре OpenBSD, например. В OpenBSD оно с каждым годом стремительно уменьшается. Вы, конечно, можете крикнуть: "потому что скрывают!". Но я пока не видел этому подтверждений, хотя честно читаю source-changes@, и разглядываю все настораживающие коммиты.

>> "на соседнем участке". Это действительно, понятно даже ёжику. Но по вашей
> Это заблуждение, которое различным ёжиком привили люди, вроде Бернштейна и разработчиков
> OpenBSD, отвлекая внимание от проблемы самого слабого звена.

Какое заблуждение? Вы вообще о чём? О том, что изоляция привилегий полезна? Я не пойму, вы на пару с этим товарищем не понимаете, против чего вообще эта защитная мера нужна, что ли? Ядро она не защищает, да, ну так и доклад-то был не "защитные техники ядра OpenBSD", не? Каша у вас какая-то.

>> логике, получается, вообще ничего делать не надо, если только не всё
> По моей логике, реализовав разделение привилегий, нужно браться за усиление ядра, или
> наоборот.

Это ортогональные вещи, почему г-н Альбертс сплёл их вместе - только ему и известно.

>> сразу? Была произведена подмена темы, вы разве не видите? Вместо защитного
> Не вижу. Обсуждаем звенья одной цепи.

Да, но РАЗНЫЕ звенья. Вот вам цепь, пять звеньев. Первое, второе и третье держат до 50 ньютонов, четвёртое до 30, пятое до 20. Усилили пятое, теперь оно тоже держит 50 ньютонов. Вопль со стороны: "да нафига делали, всё равно порвётся". Цена этому воплю знаете, какая?

>> механизма речь зашла о совсем другом участке кода. Из серии: "Ну
>> и что, что 4x4, всё равно задних сидений нет". Это был
>> банальный софизм, а вы его ещё и защищаете почему-то.
> Этот "софизм" совпадает с моими собственными выводами.

Печально.