forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Анализ безопасности показал переоценку защиты с использовани..., opennews (ok), 10-Янв-11, (0) [смотреть все]

Мне кажется или здесь попахивает Капитаном , zazik (ok), 13:39 , 10-Янв-11, (1) +1 //

кажется, szh (ok), 15:01 , 10-Янв-11, (10) +1

Судя по названию capabillities, Капитан чего-то озаботился capabilities , User294 (ok), 13:57 , 10-Янв-11, (3) –4 //

Я к тому, что, получив capabilities на SETUID, приложение вполне ожидаемо может , zazik (ok), 14:09 , 10-Янв-11, (4) +2

Дык а какого черта приложения не сбрасывают свои capabilites после того, как вып, Vasily Pupkin (?), 14:23 , 10-Янв-11, (5) //

У трояна тоже это будешь спрашивать Какой нихароший, не сбросил свои капабил, pavlinux (ok), 15:07 , 10-Янв-11, (12) +2 //

Причем тут троян Вы надавали трояну капы вы надавали трояну suid root , Vasily Pupkin (?), 16:27 , 10-Янв-11, (15) +2

А если они ещё нужны Уже сброшенное обратно не вернёшь , Frank (ok), 08:02 , 11-Янв-11, (21) //

А для чего такое может понадобится Сделал дело - отдай capabilities Иначе SETU, zazik (ok), 09:25 , 11-Янв-11, (22)
То отделяют worker ов с уже пониженными привилегиями от процесса, который держит, Michael Shigorin (ok), 12:16 , 15-Янв-11, (28)

Собственно, ничего страшного Вполне себе осмысленный анализ, который говорит, ч, Аноним (-), 14:33 , 10-Янв-11, (6) //

не у некоторых , а у большинства, что в корне меняет дело Усложнять систему ра, szh (ok), 14:52 , 10-Янв-11, (8) +1
Проблема в том, что большая часть suid-прог сбрасывают привилегии на начальной ф, Аноним (-), 14:58 , 10-Янв-11, (9) +5
Читайте внимательнее SUID-программа может сбросить свои привилегии и нормальны, PereresusNeVlezaetBuggy (ok), 15:06 , 10-Янв-11, (11) //

Беглый поиск по гуглу показал, что Each thread has three capability sets contain, цацуа (?), 15:49 , 10-Янв-11, (13) +3 //

Угу, вот собсно код проверки в kernel capability c, capset 2 code if get_use, PereresusNeVlezaetBuggy (ok), 16:43 , 10-Янв-11, (17) +3

До кучи http seclists org oss-sec 2010 q4 123http www lst de okir blackhats, Michael Shigorin (ok), 23:47 , 10-Янв-11, (20)

Молодец дядька В который раз уже молодец Стабильно раз в год показывает преиму, Аноним (-), 14:33 , 10-Янв-11, (7) +6 //

Всё должно пребывать в гармонии GRSecurity это конечно хорошо, но в ванильке ег, Vasily Pupkin (?), 16:32 , 10-Янв-11, (16) +1

В том виде, в каком оно существует capabilities , оно уже похоже на костыль Воз, анонимиус (?), 16:20 , 10-Янв-11, (14) –1
А solaris privileges это тоже касается В солярке, afaik, на привилегиях практиче, анон (?), 16:49 , 10-Янв-11, (18) +1 //

Ну и в винде примерно аналогично Для каждого потока создается свой уровень дост, letsmac (ok), 00:02 , 12-Янв-11, (23) –5 //

Это почему Принципы-то те же А что, сейчас они не нормальные , non anon (?), 10:20 , 12-Янв-11, (24) //

да это просто была стандартная попытка неуча заполучить очки, смешав в кучу слаб, ананим (?), 13:16 , 12-Янв-11, (25) +1

Это один фиг только больше и толще и современнее Капабилитис из той же кучи , letsmac (ok), 23:40 , 12-Янв-11, (26)

выражение один фиг - это тупые коментарии недоучек, пытающихся выдать своё нев, ананим (?), 00:01 , 13-Янв-11, (27)

Сообщения [Сортировка по времени | RSS]

6. "Анализ безопасности показал переоценку защиты с использовани..." +/–

Сообщение от Аноним (-), 10-Янв-11, 14:33

Собственно, ничего страшного. Вполне себе осмысленный анализ, который говорит, что у некоторых capabilities в определенных ситуацияз могут быть проблемы. Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права. Так что федора и убунту могут спокойно заниматься переводом с суид дальше, смысл от этого есть, надо только учесть то что тут обнаружено.

Ответить | Правка | Наверх | Cообщить модератору

8. "Анализ безопасности показал переоценку защиты с использовани..." +1 +/–

Сообщение от szh (ok), 10-Янв-11, 14:52

не у "некоторых", а у большинства, что в корне меняет дело. Усложнять систему ради минимальной пользы глупо.

Ответить | Правка | Наверх | Cообщить модератору

9. "Анализ безопасности показал переоценку защиты с использовани..." +5 +/–

Сообщение от Аноним (-), 10-Янв-11, 14:58

> Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права.
Проблема в том, что большая часть suid-прог сбрасывают привилегии на начальной фазе инициализации, а деятели из Fedora/Ubuntu этого не учитывают и заменяют suid на capabilities без добавления в код сброса capabilities, поэтому в итоге вместо кучи suid-программ, которые можно эксплуатировать на начальной стадии работы (например, через дыру в libc), получаем кучу программ для которых capabilities включены постоянно и эксплуатировать их можно на любой стадии их работы. Например, сломав ping получим возможность неограниченного сниффинга трафика, а httpd - возможность биндить на любой нижний порт.

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

11. "Анализ безопасности показал переоценку защиты с использовани..." +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 10-Янв-11, 15:06

Читайте внимательнее: SUID-программа может сбросить свои привилегии (и нормальные программы так и делают после запуска), после чего становится "не опасной". Тот же ping, например: открывает сырой сокет с рутовыми привилегиями, дропает привилегии и дальше работает из-под юзера.
А вот в случае с capabilities, насколько удалось понять[1], это невозможно: можно лишь перманентно отнять соответствующую привилегию у программы, другой программой, имеющей спецпривилегию CAP_SETPCAP. То есть «безопасность» получается — это когда ты запускаешь прогу, пытаешься угадать, когда же она закончит требующую рутовых прав инициализацию, и затем отдельной прогой убираешь соответствующие привилегии. Думаю, не надо объяснять, насколько это криво...
--
[1] http://www.kernel.org/pub/linux/libs/security/linux-privs/ke...

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

13. "Анализ безопасности показал переоценку защиты с использовани..." +3 +/–

Сообщение от цацуа (?), 10-Янв-11, 15:49

Беглый поиск по гуглу показал, что:
Each thread has three capability sets containing zero or more of the above capabilities:
Permitted:
This is a limiting superset for the effective capabilities that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheritable set by a thread that does not have the CAP_SETPCAP capability in its effective set.
If a thread drops a capability from its permitted set, it can never re-acquire that capability (unless it execve(2)s either a set-user-ID-root program, or a program whose associated file capabilities grant that capability).

То есть вполне очевидно что сбросить эти флажки можно, ровно в том же духе что и суид.
Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы пропатчить код суидных программ - дропать capabilities вместо suid/sgid/

Ответить | Правка | Наверх | Cообщить модератору

17. "Анализ безопасности показал переоценку защиты с использовани..." +3 +/–

Сообщение от PereresusNeVlezaetBuggy (ok), 10-Янв-11, 16:43

> То есть вполне очевидно что сбросить эти флажки можно, ровно в том
> же духе что и суид.
> Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы
> пропатчить код суидных программ - дропать capabilities вместо suid/sgid/
Угу, вот собсно код проверки в kernel/capability.c, capset(2):
    if (get_user(pid, &header->pid))
        return -EFAULT;
    /* may only affect current now */
    if (pid != 0 && pid != task_pid_vnr(current))
        return -EPERM;
И код обновления привилегий в security/commoncap.c:
int cap_capset(struct cred *new,
           const struct cred *old,
           const kernel_cap_t *effective,
           const kernel_cap_t *inheritable,
           const kernel_cap_t *permitted)
{
    if (cap_inh_is_capped() &&
        !cap_issubset(*inheritable,
              cap_combine(old->cap_inheritable,
                      old->cap_permitted)))
        /* incapable of using this inheritable set */
        return -EPERM;
    if (!cap_issubset(*inheritable,
              cap_combine(old->cap_inheritable,
                      old->cap_bset)))
        /* no new pI capabilities outside bounding set */
        return -EPERM;
    /* verify restrictions on target's new Permitted set */
    if (!cap_issubset(*permitted, old->cap_permitted))
        return -EPERM;
    /* verify the _new_Effective_ is a subset of the _new_Permitted_ */
    if (!cap_issubset(*effective, *permitted))
        return -EPERM;
    new->cap_effective   = *effective;
    new->cap_inheritable = *inheritable;
    new->cap_permitted   = *permitted;
    return 0;
}
Значит, претензия действительно чисто к невнимательным товарищам из Ubuntu & Co.

Ответить | Правка | Наверх | Cообщить модератору

20. "Анализ безопасности показал переоценку защиты с использовани..." +/–

Сообщение от Michael Shigorin (ok), 10-Янв-11, 23:47

До кучи:
http://seclists.org/oss-sec/2010/q4/123
http://www.lst.de/~okir/blackhats/node125.html
http://tldp.org/HOWTO/Secure-Programs-HOWTO/minimize-privile...

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

6. "Анализ безопасности показал переоценку защиты с использовани..."	+/–
Сообщение от Аноним (-), 10-Янв-11, 14:33
Собственно, ничего страшного. Вполне себе осмысленный анализ, который говорит, что у некоторых capabilities в определенных ситуацияз могут быть проблемы. Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права. Так что федора и убунту могут спокойно заниматься переводом с суид дальше, смысл от этого есть, надо только учесть то что тут обнаружено.
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Анализ безопасности показал переоценку защиты с использовани..."	+1 +/–
	Сообщение от szh (ok), 10-Янв-11, 14:52
	не у "некоторых", а у большинства, что в корне меняет дело. Усложнять систему ради минимальной пользы глупо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	9. "Анализ безопасности показал переоценку защиты с использовани..."	+5 +/–
	Сообщение от Аноним (-), 10-Янв-11, 14:58
	> Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права. Проблема в том, что большая часть suid-прог сбрасывают привилегии на начальной фазе инициализации, а деятели из Fedora/Ubuntu этого не учитывают и заменяют suid на capabilities без добавления в код сброса capabilities, поэтому в итоге вместо кучи suid-программ, которые можно эксплуатировать на начальной стадии работы (например, через дыру в libc), получаем кучу программ для которых capabilities включены постоянно и эксплуатировать их можно на любой стадии их работы. Например, сломав ping получим возможность неограниченного сниффинга трафика, а httpd - возможность биндить на любой нижний порт.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	11. "Анализ безопасности показал переоценку защиты с использовани..."	+/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 10-Янв-11, 15:06
	Читайте внимательнее: SUID-программа может сбросить свои привилегии (и нормальные программы так и делают после запуска), после чего становится "не опасной". Тот же ping, например: открывает сырой сокет с рутовыми привилегиями, дропает привилегии и дальше работает из-под юзера. А вот в случае с capabilities, насколько удалось понять[1], это невозможно: можно лишь перманентно отнять соответствующую привилегию у программы, другой программой, имеющей спецпривилегию CAP_SETPCAP. То есть «безопасность» получается — это когда ты запускаешь прогу, пытаешься угадать, когда же она закончит требующую рутовых прав инициализацию, и затем отдельной прогой убираешь соответствующие привилегии. Думаю, не надо объяснять, насколько это криво... -- [1] http://www.kernel.org/pub/linux/libs/security/linux-privs/ke...
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	13. "Анализ безопасности показал переоценку защиты с использовани..."	+3 +/–
	Сообщение от цацуа (?), 10-Янв-11, 15:49
	Беглый поиск по гуглу показал, что: Each thread has three capability sets containing zero or more of the above capabilities: Permitted: This is a limiting superset for the effective capabilities that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheritable set by a thread that does not have the CAP_SETPCAP capability in its effective set. If a thread drops a capability from its permitted set, it can never re-acquire that capability (unless it execve(2)s either a set-user-ID-root program, or a program whose associated file capabilities grant that capability). То есть вполне очевидно что сбросить эти флажки можно, ровно в том же духе что и суид. Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы пропатчить код суидных программ - дропать capabilities вместо suid/sgid/
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Анализ безопасности показал переоценку защиты с использовани..."	+3 +/–
	Сообщение от PereresusNeVlezaetBuggy (ok), 10-Янв-11, 16:43
	> То есть вполне очевидно что сбросить эти флажки можно, ровно в том > же духе что и суид. > Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы > пропатчить код суидных программ - дропать capabilities вместо suid/sgid/ Угу, вот собсно код проверки в kernel/capability.c, capset(2): if (get_user(pid, &header->pid)) return -EFAULT; /* may only affect current now / if (pid != 0 && pid != task_pid_vnr(current)) return -EPERM; И код обновления привилегий в security/commoncap.c: int cap_capset(struct cred new, const struct cred old, const kernel_cap_t effective, const kernel_cap_t inheritable, const kernel_cap_t permitted) { if (cap_inh_is_capped() && !cap_issubset(inheritable, cap_combine(old->cap_inheritable, old->cap_permitted))) / incapable of using this inheritable set / return -EPERM; if (!cap_issubset(inheritable, cap_combine(old->cap_inheritable, old->cap_bset))) /* no new pI capabilities outside bounding set / return -EPERM; / verify restrictions on target's new Permitted set / if (!cap_issubset(permitted, old->cap_permitted)) return -EPERM; /* verify the _new_Effective_ is a subset of the _new_Permitted_ / if (!cap_issubset(effective, permitted)) return -EPERM; new->cap_effective = effective; new->cap_inheritable = inheritable; new->cap_permitted = permitted; return 0; } Значит, претензия действительно чисто к невнимательным товарищам из Ubuntu & Co.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	20. "Анализ безопасности показал переоценку защиты с использовани..."	+/–
	Сообщение от Michael Shigorin (ok), 10-Янв-11, 23:47
	До кучи: http://seclists.org/oss-sec/2010/q4/123 http://www.lst.de/~okir/blackhats/node125.html http://tldp.org/HOWTO/Secure-Programs-HOWTO/minimize-privile...
	Ответить \| Правка \| Наверх \| Cообщить модератору