The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Анализ безопасности показал переоценку защиты с использовани..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от opennews (ok) on 10-Янв-11, 13:39 
Брэд Спенглер (Brad Spengler), автор проекта grsecurity (http://www.grsecurity.net), представил отчет (http://forums.grsecurity.net/viewtopic.php?f=7&t=2522) с результатами оценки надежности системы "capabilities (https://www.opennet.ru/man.shtml?topic=capabilities)" в Linux, предназначенной для выборочного предоставления определенных привилегированных действий или открытия доступа к определенным ресурсам (например, утилите ping можно открыть только доступ к raw-сокету, без делегирования остальных root-прав). Проведенное исследование показало неожиданные результаты: 19 из 35 существующих "capabilities" позволили совершить действия, которые в конечном итоге потенциально могут привести к получению полноценных прав пользователя root.

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

URL: http://forums.grsecurity.net/viewtopic.php?f=7&t=2522
Новость: https://www.opennet.ru/opennews/art.shtml?num=29219

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

Оглавление

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


1. "Анализ безопасности показал переоценку защиты с использовани..."  +1 +/
Сообщение от zazik (ok) on 10-Янв-11, 13:39 
Мне кажется или здесь попахивает Капитаном?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Анализ безопасности показал переоценку защиты с использовани..."  +1 +/
Сообщение от szh (ok) on 10-Янв-11, 15:01 
кажется
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Анализ безопасности показал переоценку защиты с использовани..."  –4 +/
Сообщение от User294 (ok) on 10-Янв-11, 13:57 
Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Анализ безопасности показал переоценку защиты с использовани..."  +2 +/
Сообщение от zazik (ok) on 10-Янв-11, 14:09 
> Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)

Я к тому, что, получив capabilities на SETUID, приложение вполне ожидаемо может сделать SETUID. И т.д.

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

5. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от Vasily Pupkin email on 10-Янв-11, 14:23 
Дык а какого черта приложения не сбрасывают свои capabilites после того, как выполнят необходимые действия?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Анализ безопасности показал переоценку защиты с использовани..."  +2 +/
Сообщение от pavlinux (ok) on 10-Янв-11, 15:07 
У трояна тоже это будешь спрашивать... "Какой нихароший, не сбросил свои капабилитес"
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

15. "Анализ безопасности показал переоценку защиты с использовани..."  +2 +/
Сообщение от Vasily Pupkin email on 10-Янв-11, 16:27 
Причем тут троян? :) Вы надавали трояну капы == вы надавали трояну suid/root.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

21. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от Frank email(ok) on 11-Янв-11, 08:02 
А если они ещё нужны? Уже сброшенное обратно не вернёшь...
Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

22. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от zazik (ok) on 11-Янв-11, 09:25 
> А если они ещё нужны? Уже сброшенное обратно не вернёшь...

А для чего такое может понадобится? Сделал дело - отдай capabilities. Иначе SETUID лучше.

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

28. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от Michael Shigorin email(ok) on 15-Янв-11, 12:16 
> А если они ещё нужны? Уже сброшенное обратно не вернёшь...

То отделяют worker'ов с уже пониженными привилегиями от процесса, который держит привилегии и порождает worker'ов, но старается не вляпаться сам.

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

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

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

9. "Анализ безопасности показал переоценку защиты с использовани..."  +5 +/
Сообщение от Аноним (??) on 10-Янв-11, 14:58 
> Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права.

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

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

11. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 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 +/
Сообщение от цацуа on 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/

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

17. "Анализ безопасности показал переоценку защиты с использовани..."  +3 +/
Сообщение от PereresusNeVlezaetBuggy email(ok) on 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.

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

20. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от Michael Shigorin email(ok) on 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...
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

7. "Анализ безопасности показал переоценку защиты с использовани..."  +6 +/
Сообщение от Аноним (??) on 10-Янв-11, 14:33 
Молодец дядька. В который раз уже молодец. Стабильно раз в год показывает преимущества своего проекта над всеми остальными системами безопасности GNU/Linux. Пойду-ка зашлю ему ещё деньжат.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Анализ безопасности показал переоценку защиты с использовани..."  +1 +/
Сообщение от Vasily Pupkin email on 10-Янв-11, 16:32 
Всё должно пребывать в гармонии. GRSecurity это конечно хорошо, но в ванильке его не будет
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

14. "Анализ безопасности показал переоценку защиты с использовани..."  –1 +/
Сообщение от анонимиус on 10-Янв-11, 16:20 
В том виде, в каком оно существует(capabilities), оно уже похоже на костыль. Возможно не прав, глубоко не вникал, но как-то так.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Анализ безопасности показал переоценку защиты с использовани..."  +1 +/
Сообщение от анон on 10-Янв-11, 16:49 
А solaris privileges это тоже касается?
В солярке, afaik, на привилегиях практически вся безопасность завязана, а по сути это те же самые capabilities.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Анализ безопасности показал переоценку защиты с использовани..."  –5 +/
Сообщение от letsmac (ok) on 12-Янв-11, 00:02 
Ну и в винде примерно аналогично. Для каждого потока создается свой уровень доступа. Технология очень сложная в разрешении противоречий. Для  linux -  новая -  для соляры со своими версиями программ - очень даже безопасная. Так глядишь и ACL нормальный у пингвинов появится.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от non anon on 12-Янв-11, 10:20 
> для соляры со своими версиями программ - очень даже безопасная

Это почему? Принципы-то те же.

> Так глядишь и ACL нормальный у пингвинов появится.

А что, сейчас они не нормальные?

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

25. "Анализ безопасности показал переоценку защиты с использовани..."  +1 +/
Сообщение от ананим on 12-Янв-11, 13:16 
>> Так глядишь и ACL нормальный у пингвинов появится.
>А что, сейчас они не нормальные?

да это просто была стандартная попытка неуча заполучить очки, смешав в кучу слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и пр., и пр. ну и капабилитис до кучи.

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

26. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от letsmac (ok) on 12-Янв-11, 23:40 
> да это просто была стандартная попытка неуча заполучить очки, смешав в кучу
> слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и

Это один фиг только "больше и толще и современнее".  Капабилитис из той же кучи с той же задачей разграничения прав только для приложений. Еще один балаган c аббревиатурами.  

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

27. "Анализ безопасности показал переоценку защиты с использовани..."  +/
Сообщение от ананим on 13-Янв-11, 00:01 
выражение "один фиг" - это тупые коментарии недоучек, пытающихся выдать своё невежество за активную гражданскую позицию.
даже спорить с такими - это неуважение к себе любимому.

зы:
отмечу только один факт https://www.opennet.ru/man.shtml?topic=capabilities
>Начиная с ядра 2.2, Linux обеспечивает (хотя и не полностью) в системе много возможностей, разделяющие привилегии, традиционно ассоциированные с суперпользователем, в отдельный блок, который может быть независимо включен или выключен.

http://ru.wikipedia.org/wiki/Linux_(%D1%8F%D0%B4%D1%80%D0%BE)
>25 января 1999 — Linux версии 2.2.0, изначально довольно недоработанный (1 800 847 строк кода).

так что это такая уже древность, что все ваши инсинуации по данному вопросу просто смешны.
при чем они так и не входят в posix стандарт, в который ACL принят (тем более реализован) аж в 1998 году.

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

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

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




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

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