The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

29.10.2010 13:31

На очередном совещании управляющего совета проекта Fedora была одобрена идея полного избавления дистрибутива от приложений с установленным флагом смены пользовательского идентификатора (suid), что значительно повысит безопасность системы (например, делает невозможным эксплуатацию уязвимости в glibc). Реализовать намеченное в жизнь планируется в релизе Fedora 15.

Вместо установки suid-бита, для программ, требующих повышенных прав доступа, будут применены "capabilities", позволяющие выборочно организовать выполнение только требуемых привилегированных действий. Например, утилита ping получит возможность доступа только к raw-сокету (CAP_NET_RAW), без делегирования остальных root-прав. Для привязки capabilities к исполняемому файлу используется утилита setcap из пакета libcap2-bin, например для утилиты ping установку необходимых прав можно произвести командой "setcap cap_net_raw+ep /bin/ping".

В настоящее время для 11 пакетов уже осуществлен уход от setuid root, для 24 пакетов изменения находятся в процессе обработки. Немодифицированными будут оставлены только пакеты su, sudo, ksu и userhelper, по своей сути предназначенные для предоставления полных прав суперпользователя.

  1. Главная ссылка к новости (http://lists.fedoraproject.org...)
  2. OpenNews: Для Glibc представлен еще один метод повышения привилегий
  3. OpenNews: В Glibc обнаружена серьезная уязвимость
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/28454-security
Ключевые слова: security, capabilities, suid
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, tux2002 (ok), 16:02, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Простите за буквоедство - setuid.
     
  • 1.2, Аноним (-), 16:12, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Флаг называется S_ISUID, поэтому всё нормально
     
  • 1.3, x97rang (?), 16:13, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    молодцы ребята
     
  • 1.4, maint (?), 16:36, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    помятуя о звуке, а вообще не запретят ?
     
     
  • 2.7, tux2002 (ok), 16:52, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > помятуя о звуке, а вообще не запретят ?

    Я не знаю о чём Вы про запреты, но рут достаточно перегружен обязанностями на десктоп системах. Мне вообще кажется сегодняшнее положение - это натягивание остатков многопользовательской системы на десктоп.

     
     
  • 3.25, Michael Shigorin (ok), 22:45, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > натягивание остатков многопользовательской системы на десктоп.

    Хм, то есть однопользовательская win95 Вам как десктоп ближе?

     
     
  • 4.33, НеДобрый Аноним (?), 04:26, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а там разве хоть что-то работает в контексте пользователя? и вообще есть ли там отличие: пользователь - суперпользователь?
     
  • 4.39, tux2002 (ok), 20:33, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> натягивание остатков многопользовательской системы на десктоп.
    > Хм, то есть однопользовательская win95 Вам как десктоп ближе?

    Я хотел сказать, что по моему мнению Linux немного не для этого.

     

  • 1.5, zazik (ok), 16:46, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мне кажется, идея хорошая.
     
  • 1.6, KERNEL_PANIC (ok), 16:51, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ну отлично! Когдато находил в интернете пару трюков взлома через suid. Интересно, на новой технологии действительно безопасно?
     
     
  • 2.8, www2 (??), 17:05, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Надо полагать, что в определённой степени безопаснее, но не безопасно полностью. Например, если раньше, найдя уязвимость в ping, можно было бы получить полный доступ к системе, то теперь можно будет получить только полный доступ к сетевой подсистеме (генерировать любые пакеты и ловить любые пакеты, я так понимаю).
     
     
  • 3.9, tux2002 (ok), 17:29, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это да. Но я ещё в этом виижу всё таки уход от модели одного суперпользователя к модели с распределением обязанностей. И такие тенденции и попытки в области использования Linux прослеживаются у некоторых людей в Internet.
     
     
  • 4.12, Аноним (-), 18:01, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    наконец-то кто-то начал вспоминать о модели безопастности реализованой в Netware-3 :)
     
     
  • 5.16, tux2002 (ok), 19:38, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > наконец-то кто-то начал вспоминать о модели безопастности реализованой в Netware-3 :)

    Я незнаком с NetWare.
    Отучение exim от setuid протрахало мне мозг на два месяца.

     
     
  • 6.17, tux2002 (ok), 19:45, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И теперь наконец я знаю, что настоящий mbox имеет разрешения 602. 2 - щёлочка куда кидает письмо почтальон. 6 - пользователь открывает ключиком. Ну да вы все у себя в подъезде можете посмотреть. exin такое не умеет :(.

    Шютка :)!

    К чему это я? Ну setuid, работа в группе и т.д. и т.п. это так сзать unix way, хотя кому это нафих нужно,  к чему это я?.


     
     
  • 7.26, Michael Shigorin (ok), 22:47, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > И теперь наконец я знаю, что настоящий mbox имеет разрешения 602.
    > 2 - щёлочка куда кидает письмо почтальон.

    Не 2 (read), а 4 (write).

    > 6 - пользователь открывает ключиком.

    7, поскольку можно и заглянуть, и взять, и забросить.

    > Ну да вы все у себя в подъезде можете посмотреть. exin такое не умеет :(.

    Ну посмотрите наконец на postfix и непривилегированный procmail в альте :)

    >  к чему это я?.

    Хороший вопрос.

     
     
  • 8.28, filosofem (ok), 23:56, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ШИТО Это у вас в Альте так Чтобы враг запутался ... текст свёрнут, показать
     
     
  • 9.29, ананим (?), 00:47, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    это не почтальён, а извращенец какой-то любитель подглядывать в щёлочку, но не ... текст свёрнут, показать
     
     
  • 10.46, Аноним (-), 19:37, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    учите матчасть rwx 421 Суммируем и получаем цыфирку просба больше не порочить св... текст свёрнут, показать
     
  • 9.49, Michael Shigorin (ok), 00:54, 27/12/2011 [^] [^^] [^^^] [ответить]  
  • +/
    наткнувшись Благодарю, и впрямь переклинило ... текст свёрнут, показать
     
  • 8.36, tux2002 (ok), 11:33, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Мне серьёзно как postmaster это очень интересно, посмотрю ... текст свёрнут, показать
     
  • 4.40, leonid.ko (?), 20:50, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вы что-то перепутали тёплое с мягким. Программы не будут иметь возможности использовать ВСЕ права суперпользователя. Сама концепция суперпользователя не изменилась.
     

  • 1.10, Анонимен (?), 17:33, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А когда такое будет в ubuntu?
     
  • 1.11, anthonio (ok), 17:36, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подскажите, кто знает, а что с pppd они сделали?
     
     
  • 2.18, tux2002 (ok), 19:59, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Подскажите, кто знает, а что с pppd они сделали?

    Ты прикинь !!! Они дали разрешение группе netdev rw на /dev/ppp!!!!!

     
     
  • 3.19, tux2002 (ok), 20:00, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Подскажите, кто знает, а что с pppd они сделали?
    > Ты прикинь !!! Они дали разрешение группе netdev rw на /dev/ppp!!!!!

    Так грустноооо, что хочется куууурить!

    PS  я не проверял, но это должно быть около этого.....

     
  • 2.20, tux2002 (ok), 20:02, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Подскажите, кто знает, а что с pppd они сделали?

    Вы провоцируете :?) Дак я пьян :)

     
  • 2.22, BliecanBag (ok), 21:42, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А что не так? У меня в F14 все работает
     

  • 1.13, solardiz (ok), 18:11, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    В целом, правильно делают. Но первое время это скорее приведет даже к проблемам с безопасностью, чем к их устранению. Дело в том, что 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. :-)

     
     
  • 2.15, НеДобрый Аноним (?), 19:07, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Я думаю что он руководствуются простым принципом: меньше кода - меньше дыр.
    Если, например, посмотреть на sendmail, то у него стоит sgid, а дыр в нем находили не мало...
     
  • 2.24, Аноним (-), 22:22, 29/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Еще одна проблема - часть capabilities почти эквивалентны root'у. Например,
    > policycoreutils_setuid.patch на который есть ссылка с Features/RemoveSETUID, раздает cap_setuid,cap_dac_override,cap_sys_admin - ну и чем это отличается от root'а? Тем, что до него надо будет сделать еще один шаг? Впрочем, в случае некоторых уязвимостей, которые не позволяют прям сразу выполнить произвольный код, разница может быть более существенной.

    это набор capabilites - практически 98% возможностей рута, самое главное хватит что бы загрузить модуль с руткитом в ядро (insmod контролируется cap_sys_admin).

     
  • 2.35, paxuser (ok), 07:47, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > теряет смысл. Кстати, традиционный сисадминский подход с заходом под пользователем и
    > использованием su/sudo не выдерживает анализа и критики:

    Тут на мой взгляд беда в том, что пользователи (да и многие разработчики) питают симпатии к своим любимым системам и не готовы расстаться со сладкими заблуждениями о безопасности - слишком уж правда горька. И потому по сути бесполезные в плане безопасности ритуалы с sudo и su будут продолжаться.

    > http://www.openwall.com/lists/owl-users/2004/10/20/6

    Кстати, с тех пор в sudo появилась опция env_reset.

     
  • 2.38, szh (ok), 14:43, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Если же в дистрибутиве все равно оставлять su, sudo и т.п., это теряет смысл.

    ими можно не пользоватся, а в это время capabilities будут делать свою работу.

    > часть capabilities почти эквивалентны root'у.

    непонятно почему не сделали большее кол-во capabilities, кто мешал сделать 128 штук, кому нужна обратная совместимость если ими все равно никто не пользовался.

     
     
  • 3.42, Аноним (-), 10:34, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    потому что до 2.6.24 на это выделялся ровно один unsigned int (32bit) - позже сделали больше их, но все равно расширенными фик кто пользуется..

    в этом отношении более оптимально поступили в FreeBSD - когда rwatson@ закомитил свой аналог capabilites - их сразу было больше 30 и они более равномерно покрывали возможности супер пользователя.

     
  • 2.48, solardiz (ok), 09:18, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я поднял тему на oss-security, таким образом доведя свои соображения/опасения до разработчиков Fedora и Ubuntu:

    http://www.openwall.com/lists/oss-security/2010/11/08/3

    Может быть, это поможет делу.

     

  • 1.14, Аноним (-), 18:47, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Не прошло и 15 лет с внедрения capabilities в ядро, как их начали использовать для полной замены suid'а.

    В целом, конечно, очень позитивная новость, жаль только, что для её появления жареному петуху пришлось целый месяц долбить всех по темени. И да, на переносимости скажется :(

     
     
  • 2.30, ананим (?), 00:50, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    так в посикс их так и не взяли.
     

  • 1.21, Etch (?), 21:24, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > например, делает невозможным эксплуатацию уязвимости в glibc

    А вот и нифига, вместо ping в этой уязвимости можно юзать что угодно - sudo в том числе.

     
     
  • 2.44, Frank (??), 11:55, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Если уязвимость в коде ping, то как вы будете юзать её в sudo? Вот если уявзимость будет в sudo, тогда пожалуйста. Впрочем, сокращение suid'ных файлов ведь уменьшает поле деятельности хакеров, не так ли?
     
     
  • 3.47, Etch (?), 08:33, 01/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Читайте новость по уязвимостям в glibc - там достаточно наличия в системе любой суидной программы, наличие уязвимости в этой программе не требуется.
     

  • 1.23, User294 (ok), 22:14, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Выглядит неплохо. Только вот какие гарантии что новых дыр не налепят с этими Capabilities? Это они ожегшись на дырах в libc решили так подтянуть гайки?
     
  • 1.27, Иван Иванович Иванов (?), 23:00, 29/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Заняться нечем.

    В X.org сервере куча багов, в Gnome/KDE сотни сли не тысячи багов - они занимаются setuid бинарниками. Тьфу.

     
     
  • 2.31, ананим (?), 00:51, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >В X.org сервере куча багов,

    каких?

     
     
  • 3.37, Иван Иванович Иванов (?), 12:35, 30/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>В X.org сервере куча багов,
    > каких?

    Модераторы трут сообщения со звёздочками, вместо мата - печально.

    https://bugs.freedesktop.org/show_bug.cgi?id=25497

    И ещё не меньше сотни серьёзных багов.

    Но вы минусуйте меня дальше, фанатики. Близорукость не вылечить.

     

  • 1.34, paxuser (ok), 07:26, 30/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Тенденция хоть и похвальна, но проблему с безопасностью самого ядра дистростроители по-прежнему обходят стороной, а ведь она стоит очень остро. Например, последняя уязвимость в RDS гораздо опаснее уязвимостей в glibc (хотя последние и нагляднее в эксплуатации), поскольку позволяет не только переписать *uid/*gid процесса, но и вернуть его из chroot, из любых namespace'ов, вернуть любые отнятые capabilities, отключить LSM, включая распиаренный SELinux, извлечь криптоключи из памяти ядра так далее. При этом адреса объектов ядра (kallsyms) для заранее собранных ядер известны, а работа со структурами, описывающими процесс, достаточно проста и практически не создаёт рисков обрушения ядра. И таких уязвимостей, по мнение экспертов (включая Дэна Розенберга), в ядре очень много.

    Можно стремиться довести безопасность юзерленда до совершенства, и это очень хорошо, но ограничиваясь только юзерлендом, защитить систему на должном уровне не удастся, и это факт.

     
  • 1.41, ghosthunter (?), 03:58, 31/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Читайте пропатченный копипаст этой же новости на ЛОРе, там намного правдоподобнее получилось, это я вам гарантирую ;)
     
  • 1.43, СуперАноним (?), 11:07, 31/10/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А, может, не стоило городить в ядре переключение видеорежимов, а X серверу вместо SUID дать CAP_SYS_RAWIO ?
     
     
  • 2.45, tux2002 (ok), 17:48, 31/10/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А, может, не стоило городить в ядре переключение видеорежимов, а X серверу
    > вместо SUID дать CAP_SYS_RAWIO ?

    Я смог запустить X сервер c capabilities только с драйвером vesa. Какие capabilities точно не помню но rawio и что-то с доступом к /dev/kmem и т.п. Сами драйвера требуют чего то большего, я уже не стал разбираться....

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру