На очередном совещании управляющего совета проекта Fedora была одобрена (http://lists.fedoraproject.org/pipermail/devel/2010-October/...) идея полного избавления дистрибутива от приложений с установленным флагом смены пользовательского идентификатора (suid), что значительно повысит безопасность системы. Реализовать намеченное в жизнь планируется (http://fedoraproject.org/wiki/Features/RemoveSETUID) в релизе Fedora 15.
Вместо установки suid-бита, для программ, требующих повышенных прав доступа, будут применены "capabilities", позволяющие организовать выполнение только требуемых привилегированных действий. Например, утилита ping получит возможность доступа только к raw-сокету (CAP_NET_RAWIO), без делегирования полноценных root-прав. В настоящее время для 11 пакетов уже
осуществлен (https://bugzilla.redhat.com/show_bug.cgi?id=646440) уход от suid root, для 24 пакетов изменения находятся в процессе обработки.URL: http://lists.fedoraproject.org/pipermail/devel/2010-October/...
Новость: http://www.opennet.me/opennews/art.shtml?num=28454
Простите за буквоедство - setuid.
Флаг называется S_ISUID, поэтому всё нормально
молодцы ребята
помятуя о звуке, а вообще не запретят ?
> помятуя о звуке, а вообще не запретят ?Я не знаю о чём Вы про запреты, но рут достаточно перегружен обязанностями на десктоп системах. Мне вообще кажется сегодняшнее положение - это натягивание остатков многопользовательской системы на десктоп.
> натягивание остатков многопользовательской системы на десктоп.Хм, то есть однопользовательская win95 Вам как десктоп ближе?
а там разве хоть что-то работает в контексте пользователя? и вообще есть ли там отличие: пользователь - суперпользователь?
>> натягивание остатков многопользовательской системы на десктоп.
> Хм, то есть однопользовательская win95 Вам как десктоп ближе?Я хотел сказать, что по моему мнению Linux немного не для этого.
Мне кажется, идея хорошая.
Ну отлично! Когдато находил в интернете пару трюков взлома через suid. Интересно, на новой технологии действительно безопасно?
Надо полагать, что в определённой степени безопаснее, но не безопасно полностью. Например, если раньше, найдя уязвимость в ping, можно было бы получить полный доступ к системе, то теперь можно будет получить только полный доступ к сетевой подсистеме (генерировать любые пакеты и ловить любые пакеты, я так понимаю).
Это да. Но я ещё в этом виижу всё таки уход от модели одного суперпользователя к модели с распределением обязанностей. И такие тенденции и попытки в области использования Linux прослеживаются у некоторых людей в Internet.
наконец-то кто-то начал вспоминать о модели безопастности реализованой в Netware-3 :)
> наконец-то кто-то начал вспоминать о модели безопастности реализованой в Netware-3 :)Я незнаком с NetWare.
Отучение exim от setuid протрахало мне мозг на два месяца.
И теперь наконец я знаю, что настоящий mbox имеет разрешения 602. 2 - щёлочка куда кидает письмо почтальон. 6 - пользователь открывает ключиком. Ну да вы все у себя в подъезде можете посмотреть. exin такое не умеет :(.Шютка :)!
К чему это я? Ну setuid, работа в группе и т.д. и т.п. это так сзать unix way, хотя кому это нафих нужно, к чему это я?.
> И теперь наконец я знаю, что настоящий mbox имеет разрешения 602.
> 2 - щёлочка куда кидает письмо почтальон.Не 2 (read), а 4 (write).
> 6 - пользователь открывает ключиком.
7, поскольку можно и заглянуть, и взять, и забросить.
> Ну да вы все у себя в подъезде можете посмотреть. exin такое не умеет :(.
Ну посмотрите наконец на postfix и непривилегированный procmail в альте :)
> к чему это я?.
Хороший вопрос.
>Не 2 (read), а 4 (write).ШИТО?
Это у вас в Альте так??? Чтобы враг запутался? =)
>602. 2 - щёлочка куда кидает письмо почтальон.это не почтальён, а извращенец какой-то. любитель подглядывать в щёлочку, но не кидать.
учите матчасть
rwx
421
Суммируем и получаем цыфирку
просба больше не порочить святое имя анонима
>>Не 2 (read), а 4 (write).
> ШИТО?(наткнувшись) Благодарю, и впрямь переклинило.
> Ну посмотрите наконец на postfix и непривилегированный procmail в альте :)Мне серьёзно как postmaster это очень интересно, посмотрю.
Вы что-то перепутали тёплое с мягким. Программы не будут иметь возможности использовать ВСЕ права суперпользователя. Сама концепция суперпользователя не изменилась.
А когда такое будет в ubuntu?
Подскажите, кто знает, а что с pppd они сделали?
> Подскажите, кто знает, а что с pppd они сделали?Ты прикинь !!! Они дали разрешение группе netdev rw на /dev/ppp!!!!!
>> Подскажите, кто знает, а что с pppd они сделали?
> Ты прикинь !!! Они дали разрешение группе netdev rw на /dev/ppp!!!!!Так грустноооо, что хочется куууурить!
PS я не проверял, но это должно быть около этого.....
> Подскажите, кто знает, а что с pppd они сделали?Вы провоцируете :?) Дак я пьян :)
А что не так? У меня в F14 все работает
В целом, правильно делают. Но первое время это скорее приведет даже к проблемам с безопасностью, чем к их устранению. Дело в том, что 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. :-)
Я думаю что он руководствуются простым принципом: меньше кода - меньше дыр.
Если, например, посмотреть на sendmail, то у него стоит sgid, а дыр в нем находили не мало...
> Еще одна проблема - часть capabilities почти эквивалентны root'у. Например,
> policycoreutils_setuid.patch на который есть ссылка с Features/RemoveSETUID, раздает cap_setuid,cap_dac_override,cap_sys_admin - ну и чем это отличается от root'а? Тем, что до него надо будет сделать еще один шаг? Впрочем, в случае некоторых уязвимостей, которые не позволяют прям сразу выполнить произвольный код, разница может быть более существенной.это набор capabilites - практически 98% возможностей рута, самое главное хватит что бы загрузить модуль с руткитом в ядро (insmod контролируется cap_sys_admin).
> теряет смысл. Кстати, традиционный сисадминский подход с заходом под пользователем и
> использованием su/sudo не выдерживает анализа и критики:Тут на мой взгляд беда в том, что пользователи (да и многие разработчики) питают симпатии к своим любимым системам и не готовы расстаться со сладкими заблуждениями о безопасности - слишком уж правда горька. И потому по сути бесполезные в плане безопасности ритуалы с sudo и su будут продолжаться.
> http://www.openwall.com/lists/owl-users/2004/10/20/6
Кстати, с тех пор в sudo появилась опция env_reset.
> Если же в дистрибутиве все равно оставлять su, sudo и т.п., это теряет смысл.ими можно не пользоватся, а в это время capabilities будут делать свою работу.
> часть capabilities почти эквивалентны root'у.
непонятно почему не сделали большее кол-во capabilities, кто мешал сделать 128 штук, кому нужна обратная совместимость если ими все равно никто не пользовался.
потому что до 2.6.24 на это выделялся ровно один unsigned int (32bit) - позже сделали больше их, но все равно расширенными фик кто пользуется..в этом отношении более оптимально поступили в FreeBSD - когда rwatson@ закомитил свой аналог capabilites - их сразу было больше 30 и они более равномерно покрывали возможности супер пользователя.
Я поднял тему на oss-security, таким образом доведя свои соображения/опасения до разработчиков Fedora и Ubuntu:http://www.openwall.com/lists/oss-security/2010/11/08/3
Может быть, это поможет делу.
Не прошло и 15 лет с внедрения capabilities в ядро, как их начали использовать для полной замены suid'а.В целом, конечно, очень позитивная новость, жаль только, что для её появления жареному петуху пришлось целый месяц долбить всех по темени. И да, на переносимости скажется :(
так в посикс их так и не взяли.
> например, делает невозможным эксплуатацию уязвимости в glibcА вот и нифига, вместо ping в этой уязвимости можно юзать что угодно - sudo в том числе.
Если уязвимость в коде ping, то как вы будете юзать её в sudo? Вот если уявзимость будет в sudo, тогда пожалуйста. Впрочем, сокращение suid'ных файлов ведь уменьшает поле деятельности хакеров, не так ли?
Читайте новость по уязвимостям в glibc - там достаточно наличия в системе любой суидной программы, наличие уязвимости в этой программе не требуется.
Выглядит неплохо. Только вот какие гарантии что новых дыр не налепят с этими Capabilities? Это они ожегшись на дырах в libc решили так подтянуть гайки?
Заняться нечем.В X.org сервере куча багов, в Gnome/KDE сотни сли не тысячи багов - они занимаются setuid бинарниками. Тьфу.
>В X.org сервере куча багов,каких?
>>В X.org сервере куча багов,
> каких?Модераторы трут сообщения со звёздочками, вместо мата - печально.
https://bugs.freedesktop.org/show_bug.cgi?id=25497
И ещё не меньше сотни серьёзных багов.
Но вы минусуйте меня дальше, фанатики. Близорукость не вылечить.
Тенденция хоть и похвальна, но проблему с безопасностью самого ядра дистростроители по-прежнему обходят стороной, а ведь она стоит очень остро. Например, последняя уязвимость в RDS гораздо опаснее уязвимостей в glibc (хотя последние и нагляднее в эксплуатации), поскольку позволяет не только переписать *uid/*gid процесса, но и вернуть его из chroot, из любых namespace'ов, вернуть любые отнятые capabilities, отключить LSM, включая распиаренный SELinux, извлечь криптоключи из памяти ядра так далее. При этом адреса объектов ядра (kallsyms) для заранее собранных ядер известны, а работа со структурами, описывающими процесс, достаточно проста и практически не создаёт рисков обрушения ядра. И таких уязвимостей, по мнение экспертов (включая Дэна Розенберга), в ядре очень много.Можно стремиться довести безопасность юзерленда до совершенства, и это очень хорошо, но ограничиваясь только юзерлендом, защитить систему на должном уровне не удастся, и это факт.
Читайте пропатченный копипаст этой же новости на ЛОРе, там намного правдоподобнее получилось, это я вам гарантирую ;)
А, может, не стоило городить в ядре переключение видеорежимов, а X серверу вместо SUID дать CAP_SYS_RAWIO ?
> А, может, не стоило городить в ядре переключение видеорежимов, а X серверу
> вместо SUID дать CAP_SYS_RAWIO ?Я смог запустить X сервер c capabilities только с драйвером vesa. Какие capabilities точно не помню но rawio и что-то с доступом к /dev/kmem и т.п. Сами драйвера требуют чего то большего, я уже не стал разбираться....