>[оверквотинг удален]
>>> об экспертах однозначно положительное мнение. ;) Но главное - эти люди
>>> надёжные, им можно верить. ;)
>> А если без сарказма? И главное - если такой вот централизованный список
> Да я уже устал повторять. И не я один. В IRC эта
> тема за последние несколько лет поднималась на разных каналах не один
> десяток раз. В листах рассылки, вроде, тоже проскакивало. И все, кто
> думал своей головой и не затыкал уши, выводы давно сделали.
> Суть в том, что разработчики OpenBSD отказались изучать возможности эксплуатации уязвимости
> в коде IPv6 и объявили её DoS-уязвимостью. После чего Core Security
> представила рабочий PoC-эксплойт.http://marc.info/?l=openbsd-misc&m=117404837006368&w=2
Ошибкой OpenBSD-шников было в первую очередь то, что они доверились (скороспешному) анализу ребят из Core Security. То, что это возможность для удалённого выполнения кода, выяснилось позднее. У Core Security на это выяснение ушла неделя. Да, они молодцы, что докопались до самого конца. Но представление разработчиков OpenBSD как игнорирующих проблему - это уже, мягко говоря, перебор.
> Более того, в качестве меры защиты от эксплуатации Core Security предложила разработчикам
> идею и предварительный патч в несколько срок, с примитивной реализацией W^X
> для адра (аналог KERNEXEC на базе сегментов x86). Где W^X в
> ядре? Где гарантии, что разработчики OpenBSD не проигнорируют уязвимости в будущем?
По поводу игнорирования см. выше.
Насчёт W^X в ядре, полноценного, насколько знаю, нет. Однако записать в область ядра процесс не может изначально, только само ядро может "ошибиться" и перезаписать собственный код. Учитывая, что страницы кода и данных не смежные, нужно подсунуть в какой-то функции ядра вместо указателя на выделенную для данных область памяти - указатель на область кода ядра. Как это сделать, не имея уже исполнения собственного кода в ядре либо возможности перезаписать код (т.е., выполненной задачи), я пока что-то не представляю.
> Где документация для проведения peer review с описанием принципов и путей
> их реализации?
Вы повторяетесь. :)
> Где, хотя бы, детальные комментарии в коде? Ничего нет.
Гм. А какие вам нужны комментарии к этому?
case DIOCGETRULE:
if (((struct pfioc_rule *)addr)->action ==
PF_GET_CLR_CNTR)
return (EACCES);
break;
Или почему этот комментарий не детальный?
/*
* Check if a process is allowed to fiddle with the memory of another.
*
* p = tracer
* t = tracee
*
* 1. You can't attach to a process not owned by you or one that has raised
* its privileges.
* 1a. ...unless you are root.
*
* 2. init is always off-limits because it can control the securelevel.
* 2a. ...unless securelevel is permanently set to insecure.
*
* 3. Processes that are in the process of doing an exec() are always
* off-limits because of the can of worms they are. Just wait a
* second.
*/
int
process_checkioperm(struct proc *p, struct proc *t)
{
> Вы как хотите, а я таким экспертам доверять не стану.
Ваше право.
>> будет опубликован, это ли не будет как раз "верить на слово",
>> вместо того, чтобы самому смотреть детали?
> Лично меня интересует не список, а документация. Но нет даже списка, не
> говоря уже о таблице с непроставленными галочками напротив пунктов, которые надо
> бы реализовать.
Список с галочками (общий, не только по безопасности) раньше был, прямо на сайте. Толку от него было только чуть, никто не рвался в бой. Ну и убрали, ибо лучше без списка, чем с неактуальным. Правда, как источник информации для ревью он не расценивался.
А насчёт документации - давайте оформим ваше претензию серьёзно. Что, зачем и как должно быть. Если возможно, с примерами. А то язвить-то много ума не надо, но это как-то не конструктивно. :)
