| 1.3, User294 (ok), 13:57, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
 Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)
| | |
| |
| 2.4, zazik (ok), 14:09, 10/01/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)
Я к тому, что, получив capabilities на SETUID, приложение вполне ожидаемо может сделать SETUID. И т.д.
| | |
|
| 1.5, Vasily Pupkin (?), 14:23, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Дык а какого черта приложения не сбрасывают свои capabilites после того, как выполнят необходимые действия?
| | |
| |
| 2.12, pavlinux (ok), 15:07, 10/01/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
 У трояна тоже это будешь спрашивать... "Какой нихароший, не сбросил свои капабилитес"
| | |
| |
| 3.22, zazik (ok), 09:25, 11/01/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> А если они ещё нужны? Уже сброшенное обратно не вернёшь...
А для чего такое может понадобится? Сделал дело - отдай capabilities. Иначе SETUID лучше.
| | |
| 3.28, Michael Shigorin (ok), 12:16, 15/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 > А если они ещё нужны? Уже сброшенное обратно не вернёшь...
То отделяют worker'ов с уже пониженными привилегиями от процесса, который держит привилегии и порождает worker'ов, но старается не вляпаться сам.
| | |
|
|
| 1.6, Аноним (-), 14:33, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Собственно, ничего страшного. Вполне себе осмысленный анализ, который говорит, что у некоторых capabilities в определенных ситуацияз могут быть проблемы. Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права. Так что федора и убунту могут спокойно заниматься переводом с суид дальше, смысл от этого есть, надо только учесть то что тут обнаружено.
| | |
| |
| 2.8, szh (ok), 14:52, 10/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 не у "некоторых", а у большинства, что в корне меняет дело. Усложнять систему ради минимальной пользы глупо.
| | |
| 2.9, Аноним (-), 14:58, 10/01/2011 [^] [^^] [^^^] [ответить]
| +5 +/– | |
> Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права.
Проблема в том, что большая часть suid-прог сбрасывают привилегии на начальной фазе инициализации, а деятели из Fedora/Ubuntu этого не учитывают и заменяют suid на capabilities без добавления в код сброса capabilities, поэтому в итоге вместо кучи suid-программ, которые можно эксплуатировать на начальной стадии работы (например, через дыру в libc), получаем кучу программ для которых capabilities включены постоянно и эксплуатировать их можно на любой стадии их работы. Например, сломав ping получим возможность неограниченного сниффинга трафика, а httpd - возможность биндить на любой нижний порт.
| | |
| 2.11, PereresusNeVlezaetBuggy (ok), 15:06, 10/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Читайте внимательнее: SUID-программа может сбросить свои привилегии (и нормальные программы так и делают после запуска), после чего становится "не опасной". Тот же ping, например: открывает сырой сокет с рутовыми привилегиями, дропает привилегии и дальше работает из-под юзера.
А вот в случае с capabilities, насколько удалось понять[1], это невозможно: можно лишь перманентно отнять соответствующую привилегию у программы, другой программой, имеющей спецпривилегию CAP_SETPCAP. То есть «безопасность» получается — это когда ты запускаешь прогу, пытаешься угадать, когда же она закончит требующую рутовых прав инициализацию, и затем отдельной прогой убираешь соответствующие привилегии. Думаю, не надо объяснять, насколько это криво...
--
[1] http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-0
| | |
| |
| 3.13, цацуа (?), 15:49, 10/01/2011 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Беглый поиск по гуглу показал, что:
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/
| | |
| |
| 4.17, PereresusNeVlezaetBuggy (ok), 16:43, 10/01/2011 [^] [^^] [^^^] [ответить]
| +3 +/– |
> То есть вполне очевидно что сбросить эти флажки можно, ровно в том
> же духе что и суид.
> Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы
> пропатчить код суидных программ - дропать 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.
| | |
|
|
|
| 1.7, Аноним (-), 14:33, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Молодец дядька. В который раз уже молодец. Стабильно раз в год показывает преимущества своего проекта над всеми остальными системами безопасности GNU/Linux. Пойду-ка зашлю ему ещё деньжат.
| | |
| |
| 2.16, Vasily Pupkin (?), 16:32, 10/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Всё должно пребывать в гармонии. GRSecurity это конечно хорошо, но в ванильке его не будет
| | |
|
| 1.14, анонимиус (?), 16:20, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
В том виде, в каком оно существует(capabilities), оно уже похоже на костыль. Возможно не прав, глубоко не вникал, но как-то так.
| | |
| 1.18, анон (?), 16:49, 10/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А solaris privileges это тоже касается?
В солярке, afaik, на привилегиях практически вся безопасность завязана, а по сути это те же самые capabilities.
| | |
| |
| 2.23, letsmac (ok), 00:02, 12/01/2011 [^] [^^] [^^^] [ответить]
| –5 +/– |
 Ну и в винде примерно аналогично. Для каждого потока создается свой уровень доступа. Технология очень сложная в разрешении противоречий. Для linux - новая - для соляры со своими версиями программ - очень даже безопасная. Так глядишь и ACL нормальный у пингвинов появится.
| | |
| |
| 3.24, non anon (?), 10:20, 12/01/2011 [^] [^^] [^^^] [ответить]
| +/– | |
> для соляры со своими версиями программ - очень даже безопасная
Это почему? Принципы-то те же.
> Так глядишь и ACL нормальный у пингвинов появится.
А что, сейчас они не нормальные?
| | |
| |
| 4.25, ананим (?), 13:16, 12/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Так глядишь и ACL нормальный у пингвинов появится.
>А что, сейчас они не нормальные?
да это просто была стандартная попытка неуча заполучить очки, смешав в кучу слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и пр., и пр. ну и капабилитис до кучи.
| | |
| |
| 5.26, letsmac (ok), 23:40, 12/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
> да это просто была стандартная попытка неуча заполучить очки, смешав в кучу
> слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и
Это один фиг только "больше и толще и современнее". Капабилитис из той же кучи с той же задачей разграничения прав только для приложений. Еще один балаган c аббревиатурами.
| | |
| |
| 6.27, ананим (?), 00:01, 13/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
выражение "один фиг" - это тупые коментарии недоучек, пытающихся выдать своё невежество за активную гражданскую позицию.
даже спорить с такими - это неуважение к себе любимому.
зы:
отмечу только один факт https://www.opennet.ru/man.shtml?topic=capabilities
>Начиная с ядра 2.2, Linux обеспечивает (хотя и не полностью) в системе много возможностей, разделяющие привилегии, традиционно ассоциированные с суперпользователем, в отдельный блок, который может быть независимо включен или выключен.
http://ru.wikipedia.org/wiki/Linux_(%D1%8F%D0%B4%D1&
>25 января 1999 — Linux версии 2.2.0, изначально довольно недоработанный (1 800 847 строк кода).
так что это такая уже древность, что все ваши инсинуации по данному вопросу просто смешны.
при чем они так и не входят в posix стандарт, в который ACL принят (тем более реализован) аж в 1998 году.
| | |
|
|
|
|
|
|
