Исходное сообщение
"Итоги встречи разработчиков OpenBSD в Словении: nginx займет..." Отправлено коксюзер, 28-Сен-11 03:21
Придумал, как наглядно пояснить проблему с разделением привилегий. Внимательно читаем пункты 3a и 3b: http://www.openbsd.org/papers/ven05-deraadt/mgp00034.html 3a "Большой процесс делает chroot и сбрасывает привилегии" 3b "Маленький процесс сохраняет привилегии за собой" Смысл сего действа в уменьшении количества кода, который выполняется в рамках привилегированного процесса - чем меньше код, тем меньше в нём уязвимостей (вплоть до полного их отсутствия в идеальном случае). Разумеется, внешний интерфейс к такому коду тоже должен быть максимально простым и ограниченным. Смотрим дальше, слайды 35 и 36: http://www.openbsd.org/papers/ven05-deraadt/mgp00035.html http://www.openbsd.org/papers/ven05-deraadt/mgp00036.html Что мы видим в этих схемах? Большие непривилегированные процессы выполняют наибольшее количество функций и взаимодействуют с мелкими привилегированными по очень простому и ограниченному интерфейсу. И всё, вроде бы, замечательно... Внимание, вопрос! Если бы на схемах каждый из обозначенных там процессов, включая большие непривилегированные, взаимодействовал с большим привилегированным процессом через многофункциональный сложный интерфейс, явилось бы это нарушением выше озвученных принципов разделения привилегий? Вопрос не риторический, и ответ на него однозначный: да, наличие такого процесса в схеме нарушало бы принципы разделения привилегий. Беда в том, что такой процесс в схеме есть, но не на бумаге, а в действительности. Этот процесс - ядро OpenBSD. То самое, ядро, которое: - имеет абсолютные привилегии в системе - не защищено механизмами защиты аналогично пользовательским процессам - содержит больше кода, чем любой из пользовательских процессов - содержит уязвимости и уже подвергалось эксплуатации через них - не было написано разработчиками OpenBSD с нуля - не содержит способов уменьшить сложность интерфейса с пользовательскими процессами Выводы делайте сами. Могу только съязвить, что гладко было на бумаге, да забыли про овраги. ;)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Придумал, как наглядно пояснить проблему с разделением привилегий. > Внимательно читаем пункты 3a и 3b: http://www.openbsd.org/papers/ven05-deraadt/mgp00034.html > 3a "Большой процесс делает chroot и сбрасывает привилегии" > 3b "Маленький процесс сохраняет привилегии за собой" > Смысл сего действа в уменьшении количества кода, который выполняется в рамках привилегированного > процесса - чем меньше код, тем меньше в нём уязвимостей (вплоть > до полного их отсутствия в идеальном случае). Разумеется, внешний интерфейс к > такому коду тоже должен быть максимально простым и ограниченным. > Смотрим дальше, слайды 35 и 36: > http://www.openbsd.org/papers/ven05-deraadt/mgp00035.html > http://www.openbsd.org/papers/ven05-deraadt/mgp00036.html > Что мы видим в этих схемах? Большие непривилегированные процессы выполняют наибольшее количество > функций и взаимодействуют с мелкими привилегированными по очень простому и ограниченному > интерфейсу. И всё, вроде бы, замечательно... > Внимание, вопрос! Если бы на схемах каждый из обозначенных там процессов, включая > большие непривилегированные, взаимодействовал с большим привилегированным процессом > через многофункциональный сложный интерфейс, явилось бы это нарушением выше озвученных > принципов разделения привилегий? > Вопрос не риторический, и ответ на него однозначный: да, наличие такого процесса > в схеме нарушало бы принципы разделения привилегий. > Беда в том, что такой процесс в схеме есть, но не на > бумаге, а в действительности. Этот процесс - ядро OpenBSD. То самое, > ядро, которое: > - имеет абсолютные привилегии в системе > - не защищено механизмами защиты аналогично пользовательским процессам > - содержит больше кода, чем любой из пользовательских процессов > - содержит уязвимости и уже подвергалось эксплуатации через них > - не было написано разработчиками OpenBSD с нуля > - не содержит способов уменьшить сложность интерфейса с пользовательскими процессами > Выводы делайте сами. Могу только съязвить, что гладко было на бумаге, да > забыли про овраги. ;)
	Введите код, изображенный на картинке: