Исходное сообщение
"Fedora на пути полного ухода от использования suid-программ ..." Отправлено solardiz, 29-Окт-10 18:11
В целом, правильно делают. Но первое время это скорее приведет даже к проблемам с безопасностью, чем к их устранению. Дело в том, что SUID-программы, по идее, должны быть написаны с учетом своего такого статуса, но без учета возможных capabilities. Например, ping сбрасывает root'а как только получит raw socket - даже до анализа опций командной строки. Если же ему вместо root'а дать CAP_NET_RAW, он ее не сбросит, а так и будет с ней работать дальше. В результате возможная уязвимость на этапе после возможного/бывшего сброса root'а приведет не к утечке одного raw socket'а определенного типа (как было раньше), а к утечке всего CAP_NET_RAW (создание произвольных raw sockets, а они бывают разные, и еще кое-что). Т.е. станет чуточку хуже. Это надо исправлять патчем. И так с каждым пакетом. Думаю, они это исправят постепенно. Да, последствия уязвимостей до бывшего сброса root'а сократятся, но это важно только если SUID-root программ не останется вообще ни одной, т.к. такие уязвимости следует ожидать в ld-linux.so, libc, и ядре, а не в нескольких строках кода в ping.c, которые там шли до сброса root'а. Если же в дистрибутиве все равно оставлять su, sudo и т.п., это теряет смысл. Кстати, традиционный сисадминский подход с заходом под пользователем и использованием su/sudo не выдерживает анализа и критики: http://www.openwall.com/lists/owl-users/2004/10/20/6 Еще одна проблема - часть capabilities почти эквивалентны root'у. Например, policycoreutils_setuid.patch на который есть ссылка с Features/RemoveSETUID, раздает cap_setuid,cap_dac_override,cap_sys_admin - ну и чем это отличается от root'а? Тем, что до него надо будет сделать еще один шаг? Впрочем, в случае некоторых уязвимостей, которые не позволяют прям сразу выполнить произвольный код, разница может быть более существенной. ...А еще им надо будет перейти на tcb и отказаться от SUID'а на passwd. :-)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> В целом, правильно делают. Но первое время это скорее приведет даже к > проблемам с безопасностью, чем к их устранению. Дело в том, что > SUID-программы, по идее, должны быть написаны с учетом своего такого статуса, > но без учета возможных capabilities. > Например, ping сбрасывает root'а как только получит raw socket - даже до > анализа опций командной строки. Если же ему вместо root'а дать CAP_NET_RAW, > он ее не сбросит, а так и будет с ней работать > дальше. В результате возможная уязвимость на этапе после возможного/бывшего сброса root'а > приведет не к утечке одного raw socket'а определенного типа (как было > раньше), а к утечке всего CAP_NET_RAW (создание произвольных raw sockets, а > они бывают разные, и еще кое-что). Т.е. станет чуточку хуже. Это > надо исправлять патчем. И так с каждым пакетом. Думаю, они это > исправят постепенно. > Да, последствия уязвимостей до бывшего сброса root'а сократятся, но это важно только > если SUID-root программ не останется вообще ни одной, т.к. такие уязвимости > следует ожидать в ld-linux.so, libc, и ядре, а не в нескольких > строках кода в ping.c, которые там шли до сброса root'а. Если > же в дистрибутиве все равно оставлять su, sudo и т.п., это > теряет смысл. Кстати, традиционный сисадминский подход с заходом под пользователем и > использованием su/sudo не выдерживает анализа и критики: > http://www.openwall.com/lists/owl-users/2004/10/20/6 > Еще одна проблема - часть capabilities почти эквивалентны root'у. Например, > policycoreutils_setuid.patch на который есть ссылка с Features/RemoveSETUID, раздает > cap_setuid,cap_dac_override,cap_sys_admin - ну и чем это отличается от root'а? Тем, что > до него надо будет сделать еще один шаг? Впрочем, в случае > некоторых уязвимостей, которые не позволяют прям сразу выполнить произвольный код, разница > может быть более существенной. > ...А еще им надо будет перейти на tcb и отказаться от SUID'а > на passwd. :-)
	Введите код, изображенный на картинке: