Брэд Спенглер (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
Мне кажется или здесь попахивает Капитаном?
кажется
Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)
> Судя по названию capabillities, Капитан чего-то озаботился capabilities... :)Я к тому, что, получив capabilities на SETUID, приложение вполне ожидаемо может сделать SETUID. И т.д.
Дык а какого черта приложения не сбрасывают свои capabilites после того, как выполнят необходимые действия?
У трояна тоже это будешь спрашивать... "Какой нихароший, не сбросил свои капабилитес"
Причем тут троян? :) Вы надавали трояну капы == вы надавали трояну suid/root.
А если они ещё нужны? Уже сброшенное обратно не вернёшь...
> А если они ещё нужны? Уже сброшенное обратно не вернёшь...А для чего такое может понадобится? Сделал дело - отдай capabilities. Иначе SETUID лучше.
> А если они ещё нужны? Уже сброшенное обратно не вернёшь...То отделяют worker'ов с уже пониженными привилегиями от процесса, который держит привилегии и порождает worker'ов, но старается не вляпаться сам.
Собственно, ничего страшного. Вполне себе осмысленный анализ, который говорит, что у некоторых capabilities в определенных ситуацияз могут быть проблемы. Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права. Так что федора и убунту могут спокойно заниматься переводом с суид дальше, смысл от этого есть, надо только учесть то что тут обнаружено.
не у "некоторых", а у большинства, что в корне меняет дело. Усложнять систему ради минимальной пользы глупо.
> Но все равно это гораздо лучше чем суидная прога, которая при эксплойте может получить все права.Проблема в том, что большая часть suid-прог сбрасывают привилегии на начальной фазе инициализации, а деятели из Fedora/Ubuntu этого не учитывают и заменяют suid на capabilities без добавления в код сброса capabilities, поэтому в итоге вместо кучи suid-программ, которые можно эксплуатировать на начальной стадии работы (например, через дыру в libc), получаем кучу программ для которых capabilities включены постоянно и эксплуатировать их можно на любой стадии их работы. Например, сломав ping получим возможность неограниченного сниффинга трафика, а httpd - возможность биндить на любой нижний порт.
Читайте внимательнее: SUID-программа может сбросить свои привилегии (и нормальные программы так и делают после запуска), после чего становится "не опасной". Тот же ping, например: открывает сырой сокет с рутовыми привилегиями, дропает привилегии и дальше работает из-под юзера.А вот в случае с capabilities, насколько удалось понять[1], это невозможно: можно лишь перманентно отнять соответствующую привилегию у программы, другой программой, имеющей спецпривилегию CAP_SETPCAP. То есть «безопасность» получается — это когда ты запускаешь прогу, пытаешься угадать, когда же она закончит требующую рутовых прав инициализацию, и затем отдельной прогой убираешь соответствующие привилегии. Думаю, не надо объяснять, насколько это криво...
--
[1] http://www.kernel.org/pub/linux/libs/security/linux-privs/ke...
Беглый поиск по гуглу показал, что: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/
> То есть вполне очевидно что сбросить эти флажки можно, ровно в том
> же духе что и суид.
> Таким образом, разработчикам федоры да убунты просто стоит позаботиться о том чтобы
> пропатчить код суидных программ - дропать 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.
До кучи:
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...
Молодец дядька. В который раз уже молодец. Стабильно раз в год показывает преимущества своего проекта над всеми остальными системами безопасности GNU/Linux. Пойду-ка зашлю ему ещё деньжат.
Всё должно пребывать в гармонии. GRSecurity это конечно хорошо, но в ванильке его не будет
В том виде, в каком оно существует(capabilities), оно уже похоже на костыль. Возможно не прав, глубоко не вникал, но как-то так.
А solaris privileges это тоже касается?
В солярке, afaik, на привилегиях практически вся безопасность завязана, а по сути это те же самые capabilities.
Ну и в винде примерно аналогично. Для каждого потока создается свой уровень доступа. Технология очень сложная в разрешении противоречий. Для linux - новая - для соляры со своими версиями программ - очень даже безопасная. Так глядишь и ACL нормальный у пингвинов появится.
> для соляры со своими версиями программ - очень даже безопаснаяЭто почему? Принципы-то те же.
> Так глядишь и ACL нормальный у пингвинов появится.
А что, сейчас они не нормальные?
>> Так глядишь и ACL нормальный у пингвинов появится.
>А что, сейчас они не нормальные?да это просто была стандартная попытка неуча заполучить очки, смешав в кучу слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC и пр., и пр. ну и капабилитис до кучи.
> да это просто была стандартная попытка неуча заполучить очки, смешав в кучу
> слабо понимаемые им понятия - ACL, MAC, RBAC, MLS, MIC иЭто один фиг только "больше и толще и современнее". Капабилитис из той же кучи с той же задачей разграничения прав только для приложений. Еще один балаган c аббревиатурами.
выражение "один фиг" - это тупые коментарии недоучек, пытающихся выдать своё невежество за активную гражданскую позицию.
даже спорить с такими - это неуважение к себе любимому.зы:
отмечу только один факт http://www.opennet.me/man.shtml?topic=capabilities
>Начиная с ядра 2.2, Linux обеспечивает (хотя и не полностью) в системе много возможностей, разделяющие привилегии, традиционно ассоциированные с суперпользователем, в отдельный блок, который может быть независимо включен или выключен.http://ru.wikipedia.org/wiki/Linux_(%D1%8F%D0...)
>25 января 1999 — Linux версии 2.2.0, изначально довольно недоработанный (1 800 847 строк кода).так что это такая уже древность, что все ваши инсинуации по данному вопросу просто смешны.
при чем они так и не входят в posix стандарт, в который ACL принят (тем более реализован) аж в 1998 году.