[ON] Fedora на пути полного ухода от использования suid-программ в дистрибутиве

[rssbot]

На очередном совещании управляющего совета проекта Fedora была одобрена идея полного избавления дистрибутива от приложений с установленным флагом смены пользовательского идентификатора (suid), что значительно повысит безопасность системы. Реализовать намеченное в жизнь планируется в релизе Fedora 15. Вместо установки suid-бита, для программ, требующих повышенных прав доступа, будут применены "capabilities", позволяющие организовать выполнение только требуемых привилегированных действий. Например, утилита ping получит возможность доступа только к raw-сокету (CAP_NET_RAWIO), без делегирования полноценных root-прав. В настоящее время для 11 пакетов уже осуществлен уход от suid root, для 24 пакетов изменения находятся в процессе обработки.


Источник: http://www.opennet.ru/opennews/art.shtml?num=28454


оригинал на opennet.ru

[taaroa]

...тенденция хоть и похвальна, но проблем с безопасностью самого ядра она не решает.
+ придется как то решать проблему с SUID на passwd.

[frp]

Очень, очень хорошо и похвально... Ждём, когда их примеру последуют и другие дистрибутивы.

Правда, очень интересно, как они решат проблему с passwd.

[Илуватар]

Кто-то из скептиков в другой теме (вроде бы, про уязвимости в Glibc) утверждал, что и у capabilities есть какие-то подводные камни. Не напомните?

[watashiwa_daredeska]

утверждал, что и у capabilities есть какие-то подводные камни. Не напомните?

Да ровно те же. Вместо suid bit будет extended attribute, в котором будут перечислены capabilities, которые нужно/можно дать программе. Т.е. схема ровно та же, что и с suid, хотя права даются не все сразу, а частями. Тем не менее, есть программы, у которых один фиг будут все capabilities — su, sudo и т.п. Т.е. для атаки, проведенной на glibc, можно будет просто взять не ping, как в том примере, а su|sudo.

[/dev/random]

Более того. Сейчас glibc фильтрует часть опасных переменных по факту наличия suid-бита. А будет ли она фильтровать их по capabilities? Я бы не сказал, что это так уж просто, выяснить, какие переменные опасны в сочетании с какими правами.

[taaroa]

Более того. Сейчас glibc фильтрует часть опасных переменных по факту наличия suid-бита.
А будет ли она фильтровать их по capabilities?

#342619
Status: RESOLVED
Resolution: WONTFIX
p.s. всем пофиг^W^W в Багдаде все спокойно...

Я бы не сказал, что это так уж просто, выяснить, какие переменные опасны в сочетании с какими правами.

Gradm будет. Гарантирую это.
А костыли, подобные обсуждаемому, проблему с безопасностью самого ядра не решают, еще раз повторюсь. Да, проблем (в теории) станет меньше, но все ли программы написаны с учетом этих самых CAP_* ?

[frp]

Да, проблем (в теории) станет меньше, но все ли программы написаны с учетом этих самых CAP_* ?

Может, я не прав, но AFAIK большинство программ не нужно модифицировать, чтобы они умели работать не с SUID а с capabilities. Нужно модифицировать только те, которые порождают процессы, для которых должны ограничиваться эти самые capabilities. Тоесть ping модифицировать не нужно.

Кто-то из скептиков в другой теме (вроде бы, про уязвимости в Glibc) утверждал, что и у capabilities есть какие-то подводные камни. Не напомните?

Самая большая проблема capabilities - все равно passwd, su, sudo получат все capabilities и на них возможны (и имеют смысл) атаки, связанные с недавно обнаруженными уязвимостями glibc. Тоесть он решает проблему только частично. Есть альтернативные варианты (один из них высказан в теме о уязвимости glibc), но большинство из них требуют переписывания ПО.

[taaroa]

Да, проблем (в теории) станет меньше, но все ли программы написаны с учетом этих самых CAP_* ?

Может, я не прав, но AFAIK большинство программ не нужно модифицировать, чтобы они умели работать не с SUID а с capabilities. Нужно модифицировать только те, которые порождают процессы, для которых должны ограничиваться эти самые capabilities. Тоесть ping модифицировать не нужно.

ping.