forum.opennet.ru - "Анализ безопасности показал переоценку защиты с использовани..." (26)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

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

"Анализ безопасности показал переоценку защиты с использовани..."	+/–
Сообщение от 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 (http://www.opennet.me/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 Новость: http://www.opennet.me/opennews/art.shtml?num=29219
Ответить \| Правка \| Cообщить модератору

Оглавление

Анализ безопасности показал переоценку защиты с использовани..., zazik, 13:39 , 10-Янв-11, (1) +1

Анализ безопасности показал переоценку защиты с использовани..., szh, 15:01 , 10-Янв-11, (10) +1

Анализ безопасности показал переоценку защиты с использовани..., User294, 13:57 , 10-Янв-11, (3) –4

Анализ безопасности показал переоценку защиты с использовани..., zazik, 14:09 , 10-Янв-11, (4) +2

Анализ безопасности показал переоценку защиты с использовани..., Vasily Pupkin, 14:23 , 10-Янв-11, (5)

Анализ безопасности показал переоценку защиты с использовани..., pavlinux, 15:07 , 10-Янв-11, (12) +2

Анализ безопасности показал переоценку защиты с использовани..., Vasily Pupkin, 16:27 , 10-Янв-11, (15) +2

Анализ безопасности показал переоценку защиты с использовани..., Frank, 08:02 , 11-Янв-11, (21)

Анализ безопасности показал переоценку защиты с использовани..., zazik, 09:25 , 11-Янв-11, (22)
Анализ безопасности показал переоценку защиты с использовани..., Michael Shigorin, 12:16 , 15-Янв-11, (28)

Анализ безопасности показал переоценку защиты с использовани..., Аноним, 14:33 , 10-Янв-11, (6)

Анализ безопасности показал переоценку защиты с использовани..., szh, 14:52 , 10-Янв-11, (8) +1
Анализ безопасности показал переоценку защиты с использовани..., Аноним, 14:58 , 10-Янв-11, (9) +5
Анализ безопасности показал переоценку защиты с использовани..., PereresusNeVlezaetBuggy, 15:06 , 10-Янв-11, (11)

Анализ безопасности показал переоценку защиты с использовани..., цацуа, 15:49 , 10-Янв-11, (13) +3

Анализ безопасности показал переоценку защиты с использовани..., PereresusNeVlezaetBuggy, 16:43 , 10-Янв-11, (17) +3

Анализ безопасности показал переоценку защиты с использовани..., Michael Shigorin, 23:47 , 10-Янв-11, (20)

Анализ безопасности показал переоценку защиты с использовани..., Аноним, 14:33 , 10-Янв-11, (7) +6

Анализ безопасности показал переоценку защиты с использовани..., Vasily Pupkin, 16:32 , 10-Янв-11, (16) +1

Анализ безопасности показал переоценку защиты с использовани..., анонимиус, 16:20 , 10-Янв-11, (14) –1
Анализ безопасности показал переоценку защиты с использовани..., анон, 16:49 , 10-Янв-11, (18) +1

Анализ безопасности показал переоценку защиты с использовани..., letsmac, 00:02 , 12-Янв-11, (23) –5

Анализ безопасности показал переоценку защиты с использовани..., non anon, 10:20 , 12-Янв-11, (24)

Анализ безопасности показал переоценку защиты с использовани..., ананим, 13:16 , 12-Янв-11, (25) +1

Анализ безопасности показал переоценку защиты с использовани..., letsmac, 23:40 , 12-Янв-11, (26)

Анализ безопасности показал переоценку защиты с использовани..., ананим, 00:01 , 13-Янв-11, (27)

Сообщения по теме [Сортировка по времени | 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 on 10-Янв-11, 14:23

Дык а какого черта приложения не сбрасывают свои capabilites после того, как выполнят необходимые действия?

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

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

Сообщение от pavlinux (ok) on 10-Янв-11, 15:07

У трояна тоже это будешь спрашивать... "Какой нихароший, не сбросил свои капабилитес"

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

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

Сообщение от Vasily Pupkin on 10-Янв-11, 16:27

Причем тут троян? :) Вы надавали трояну капы == вы надавали трояну suid/root.

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

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

Сообщение от Frank (ok) on 11-Янв-11, 08:02

А если они ещё нужны? Уже сброшенное обратно не вернёшь...

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

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

Сообщение от zazik (ok) on 11-Янв-11, 09:25

> А если они ещё нужны? Уже сброшенное обратно не вернёшь...
А для чего такое может понадобится? Сделал дело - отдай capabilities. Иначе SETUID лучше.

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

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

Сообщение от Michael Shigorin (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 (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 (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 (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 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

выражение "один фиг" - это тупые коментарии недоучек, пытающихся выдать своё невежество за активную гражданскую позицию.
даже спорить с такими - это неуважение к себе любимому.
зы:
отмечу только один факт http://www.opennet.me/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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

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

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

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 on 10-Янв-11, 14:23
Дык а какого черта приложения не сбрасывают свои capabilites после того, как выполнят необходимые действия?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


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


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


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


	22. "Анализ безопасности показал переоценку защиты с использовани..."	+/–
	Сообщение от zazik (ok) on 11-Янв-11, 09:25
	> А если они ещё нужны? Уже сброшенное обратно не вернёшь... А для чего такое может понадобится? Сделал дело - отдай capabilities. Иначе SETUID лучше.
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	28. "Анализ безопасности показал переоценку защиты с использовани..."	+/–
	Сообщение от Michael Shigorin (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 (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 (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 (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 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
	выражение "один фиг" - это тупые коментарии недоучек, пытающихся выдать своё невежество за активную гражданскую позицию. даже спорить с такими - это неуважение к себе любимому. зы: отмечу только один факт http://www.opennet.me/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ообщить модератору