The OpenNET Project / Index page

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

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

На очередном совещании управляющего совета проекта 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
Тип: К сведению
Ключевые слова: security, capabilities, suid
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | 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 [^] [ответить]     [к модератору]  
  • +/
    Я хотел сказать, что по моему мнению 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 [^] [ответить]     [к модератору]  
  • +/
    Надо полагать, что в определённой степени безопаснее, но не безопасно полностью ... весь текст скрыт [показать]
     
     
  • 3.9, tux2002 (ok), 17:29, 29/10/2010 [^] [ответить]     [к модератору]  
  • +/
    Это да Но я ещё в этом виижу всё таки уход от модели одного суперпользователя к... весь текст скрыт [показать]
     
     
  • 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 - щёлочка ку... весь текст скрыт [показать]
     
     
  • 7.26, Michael Shigorin (ok), 22:47, 29/10/2010 [^] [ответить]     [к модератору]  
  • –3 +/
    Не 2 read , а 4 write 7, поскольку можно и заглянуть, и взять, и забросить ... весь текст скрыт [показать]
     
     
  • 8.28, filosofem (ok), 23:56, 29/10/2010 [^] [ответить]    [к модератору]  
  • +/
    >Не 2 (read), а 4 (write).

    ШИТО?
    Это у вас в Альте так??? Чтобы враг запутался? =)

     
     
  • 9.29, ананим (?), 00:47, 30/10/2010 [^] [ответить]    [к модератору]  
  • +1 +/
    >602. 2 - щёлочка куда кидает письмо почтальон.

    это не почтальён, а извращенец какой-то. любитель подглядывать в щёлочку, но не кидать.

     
     
  • 10.46, Аноним (-), 19:37, 31/10/2010 [^] [ответить]    [к модератору]  
  • +/
    учите матчасть
    rwx
    421
    Суммируем и получаем цыфирку
    просба больше не порочить святое имя анонима
     
  • 9.49, Michael Shigorin (ok), 00:54, 27/12/2011 [^] [ответить]    [к модератору]  
  • +/
    >>Не 2 (read), а 4 (write).
    > ШИТО?

    (наткнувшись) Благодарю, и впрямь переклинило.

     
  • 8.36, tux2002 (ok), 11:33, 30/10/2010 [^] [ответить]    [к модератору]  
  • +/
    > Ну посмотрите наконец на postfix и непривилегированный procmail в альте :)

    Мне серьёзно как 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 [^] [ответить]     [к модератору]  
  • +/
    Так грустноооо, что хочется куууурить 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 [^] [ответить]     [к модератору]  
  • +/
    это набор capabilites - практически 98 возможностей рута, самое главное хватит ... весь текст скрыт [показать]
     
  • 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 - позже сд... весь текст скрыт [показать]
     
  • 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 в ядро, как их начали использовать д... весь текст скрыт [показать]
     
     
  • 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:
    Заголовок:
    Текст:


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