Я экспериментирую с возможностями Debian Gnu / Linux.

Я скопировал / bin / ping в мой текущий рабочий каталог. Как и следовало ожидать, это не работает, это был изначально setuid root.

Затем я даю ping минимальные возможности (не root) sudo /sbin/setcap cap_net_raw=ep ./ping, и мой ping работает, как и ожидалось.

Затем sudo /sbin/setcap -r ./pingотозвать эту возможность. Теперь он не работает, как ожидалось.

Я сейчас пытаюсь заставить пинг работать, используя capsh.

capsh не имеет привилегий, поэтому мне нужно запустить его как root, но затем удалить root и, следовательно, все остальные привилегии.

Я думаю, что мне также нужно secure-keep-caps, это не задокументировано capsh, но есть в руководстве по возможностям. Я получил битовые числа от /usr/include/linux/securebits.h. Они кажутся правильными, поскольку вывод --printпоказывает, что эти биты верны.

Я возился часами, пока у меня есть это.

sudo /sbin/capsh --keep=1 --secbits=0x10 --caps="cap_net_raw+epi" == --secbits=0x10 --user=${USER} --print -- -c "./ping localhost"

Однако pingошибки ping: icmp open socket: Operation not permitted, это то, что происходит, когда у него нет возможности. Также --printшоу Current: =p cap_net_raw+i, этого недостаточно, нам нужно e.

sudo /sbin/capsh --caps="cap_net_raw+epi" --print -- -c "./ping localhost"установит возможность Current: = cap_net_raw+eipэто правильно, но оставляет нас как root.

Edit-1

Я сейчас попробовал sudo /sbin/capsh --keep=1 --secbits=0x11 --caps=cap_net_raw+epi --print -- -c "touch zz; ./ping -c1 localhost;"

Это производит:

touch: cannot touch `zz': Permission denied
ping: icmp open socket: Operation not permitted

Первая ошибка ожидается как, secure-noroot: yes но вторая нетCurrent: = cap_net_raw+eip

Edit-2

Если я поставлю ==перед --print, это теперь показывает Current: = cap_net_raw+i, так что объясняет предыдущую ошибку, но не то, почему мы теряем возможность при переключении из root, хотя я secure-keep-capsдолжен это исправить.

Edit-3

Из того, что я вижу, я теряю Effective (e) и Permitted (p), когда вызывается exec. Это ожидается, но я подумал, что безопасные защитные колпачки должны остановить их потерю. Я что-то пропустил.

Edit-4

Я проводил дополнительные исследования и снова перечитывал руководство. Кажется, что обычно eи pвозможности теряются, когда: вы переключаетесь с пользователя root(или применяете его secure-noroot, тем самым делая root обычным пользователем), это можно переопределить secure-keep-caps; когда вы звоните exec, насколько я могу судить, это инвариант.

Насколько я могу судить, он работает в соответствии с руководством. Насколько я могу судить, нет ничего полезного capsh. Насколько я могу судить, чтобы использовать возможности, вам нужно: использовать файловые возможности или иметь программу, осведомленную о возможностях, которая не используется exec. Поэтому нет привилегированной обертки.

Итак, теперь мой вопрос: что мне не хватает, для чего capsh.

Edit-5

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

Версии:

• capshиз libcap2-binверсии пакета1:2.22-1.2
• перед правкой-3 я взял последнюю capshверсию git://git.debian.org/collab-maint/libcap2.gitи начал использовать ее.
• uname -a Linux richard-laptop 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux Пользовательская земля 32bit.

Возможности - это свойства процессов. Традиционно есть три набора:

• Разрешенные возможности ( p ): возможности, которые могут быть «активированы» в текущем процессе.
• Эффективные возможности ( e ): возможности, которые в настоящее время могут использоваться в текущем процессе.
• Наследуемые возможности ( i ): файловые возможности, которые могут быть унаследованы.

Программы, запускаемые с правами root, всегда имеют полностью разрешенные и эффективные возможности, поэтому «добавление» дополнительных возможностей не оказывает заметного эффекта. (Набор наследуемых возможностей обычно пуст.) Когда setcap cap_net_raw+ep pingвы включаете эти возможности по умолчанию для любого пользователя, запускающего эту программу.

К сожалению, эти возможности связаны с исполняемым файлом и не сохраняются после выполнения нового дочернего процесса. В Linux 4.3 появились возможности Ambient, которые позволяют наследовать дочерние процессы. (См. Также Преобразование возможностей во время выполнения execve () в возможностях (7) .)

Играя с возможностями, обратите внимание на эти ловушки:

• При изменении пользователя с корневого на некорневого, действующие и разрешенные возможности очищаются (см. Влияние изменений идентификатора пользователя на возможности в возможностях (7) ). Вы можете использовать --keep=1опцию, capshчтобы избежать очистки наборов.
• Набор внешних возможностей очищается при изменении идентификаторов пользователя или группы. Решение: добавьте возможности окружения после изменения идентификатора пользователя, но перед выполнением дочернего процесса.
• Возможность может быть добавлена ​​к набору окружающих возможностей только в том случае, если она уже включена в набор разрешенных и наследуемых возможностей.

capshПрограмма от libcap 2.25 не имеют возможности изменять возможности окружающей среды пока нет, но более поздние выпуски добавлять новые варианты. Обратите внимание, что порядок опций имеет большое значение. Пример использования:

sudo capsh --caps="cap_net_raw+eip cap_setpcap,cap_setuid,cap_setgid+ep" \
    --keep=1 --user=nobody --addamb=cap_net_raw -- \
    -c "./ping -c1 127.0.0.1"

Совет: вы можете добавить --printопцию в любом месте capshкомандной строки и увидеть ее текущее состояние возможностей.

Примечание: cap_setpcapнеобходимо для --addambпока cap_setuid,cap_setgidнеобходимо для --userопции.

Ответ Лекенштейна кажется точным и полным, но я попытаюсь дать другое объяснение под другим углом, которое попытается подчеркнуть проблему, которую решает окружающий набор возможностей.

Когда вы запускаете sudo capsh --user=<some_user> --Есть 2 системных вызова, которые вызывают перерасчет возможностей (и, возможно, отбрасывают):

1. setuidСогласно man capabilities:

SECBIT_KEEP_CAPS Установка этого флага позволяет потоку с одним или несколькими 0 UID сохранять свои возможности, когда он переключает все свои UID на ненулевое значение. Если этот флаг не установлен, то такой UID-переключатель приводит к потере потоком всех возможностей.

Другими словами, в нашей capshкоманде выше, мы должны убедиться, что SECBIT_KEEP_CAPS установлен во время setuidсистемного вызова. В противном случае все возможности будут потеряны. Это то, что --keep=1делает. Так что теперь команда становитсяsudo capsh --user=<some_user> --keep=1 --

2. execveЕсли мы используем --keep=1опцию, все наборы возможностей (эффективные, разрешенное, наследуемым) не сохраняются до тех пор , в execveсистемный вызов, однако execveприводит к возможности быть пересчитаны (для непривилегированных пользователей) , а также и в не столь очевидным образом. Короче говоря, до добавления набора внешних возможностей для возможности быть в «разрешенном» наборе потока после execveвызова, либо:

   • Файл должен иметь эту возможность в своем «разрешенном» наборе . Это можно сделать с помощью setcap cap_net_raw+p /bin/bash. Это делает все упражнение бесполезным, так как наборы возможностей потока (кроме ограничивающего набора) больше не имеют никакого эффекта.
   • И файл, и поток должны иметь эту возможность в своих «наследуемых» наборах . Вы можете подумать, что это setcap cap_net_raw+iбы execveсработало, но оказывается, что вызывает необратимые разрешения потока при вызове непривилегированными пользователями (за что мы в настоящее время благодарим setuid). Таким образом, нет способа удовлетворить это условие для непривилегированного пользователя.

Возможности окружения, представленные в Linux 4.3, позволяют потоку сохранять свои возможности даже после setuidнепривилегированного пользователя, за которым следует execve, без необходимости полагаться на файловые возможности.

Там может быть ошибка / функция в ядре. Там было некоторое обсуждение:

• https://bugzilla.altlinux.org/show_bug.cgi?id=16694
• http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-03/5224.html

Я понятия не имею, если что-то было сделано, чтобы исправить это.

Не поймите меня неправильно - текущее поведение безопасно. Но это настолько безопасно, что мешает тому, что должно работать.

Редактировать: Согласно http://man7.org/linux/man-pages/man7/capabilities.7.html, существует новый набор возможностей Ambient (начиная с Linux 4.3). Похоже, это позволит то, что нужно.