Фантазмы: аналог POSIX-capabilities; разрешения, определяемые пользователем

> Программа типа /bin/ping вместо проверки uid == 0 проверяет наличие разрешения CAP_PING_FLOOD

Опиши семантику этого бита и механизм проверки того, остается ли программа в рамках?

Что скажет ЛОР?

Маниловщина.

Каждая программа может вводить свои capabilities. Для ping это, например, могут быть CAP_PING_FLOOD, CAP_PING_TOS, CAP_PING_PRELOAD. В атрибутах файла /bin/ping описывается соответствие этих битов вновь введенным дополнительным разрешениям CAP_USR*, например, это CAP_USR1, CAP_USR7, CAP_USR8. Сами по себе CAP_USR* ничего не значат, их значение может определяться пользователем как угодно. Наследовнием вновь введенных разрешений управляет ядро и libcap так же, как и обычными POSIX-разрешениями.

Вместо проверки uid == 0 программа /bin/ping может вызывать функцию, которая определяет, какому разрешению соответсвует CAP_PING_FLOOD (если нужно «флудить») и имеет ли процесс это разрешение (CAP_USR1) в своем Effective set.

не проще проверять группы, которым принадлежит пользователь?
возможно я неправильно понял суть затеи.

Ну ты на вопрос-то ответь :)

Чтобы ответить на вопрос, нужно знать, как сейчас реализована поддержка capabilities в Linux, несколько лучше, чем это знаю я. (:

Я так представляю, что достаточно добавить в libcap функцию, ну например, cap_usr_check(). И программа будет при необходимости вызывать эту функцию и сама решать, что ей делать, в зависимости наличия или отсутствия разрешения у процесса. То есть, не ядро будет разрешать или не разрешать, а сама программа (в отличие от традиционных capabilities).

Тут в том вся фишка, что uid и gid почти ничего не значили, чтобы пользователь с uid = 0 был просто обычным пользователем.

Хочу придумать способ, чтобы кто-то из пользователей мог вызывать /bin/ping -f, а кто-то — не мог. При это в код программы должны вноситься наименьшие изменения, и чтобы способ был хорошо применим и для других аналогичных программ.

работоспособность бита suid, если пользователь в этой группе?

> не ядро будет разрешать или не разрешать, а сама программа (в отличие от традиционных capabilities).

Это даже не маниловщина.

Если говорить о команде ping, то может просто сделать две версии команды ping и ping-flood и через ACL, SeLinux или что ещё ограничивать пользователей в запуске этих бинарников. Или прикручивать файл конфигурации со списком пользователей.

А ещё не совсем понятно, почему «ping -f» так страшно. Ведь загадить сеть можно и через udp-сокет и я не знаю дистров в которых сразу «из коробки» был бы настроен шейпинг исходящего трафика для обычных (не root) пользователей.

кроме -f есть еще две «опасные» опции, 2^3 = 8, получается, 8 вариантов команды пинг: ping. ping-flood, ping-tos-preload и т.д. Не ня…

Ну делить flood и preload это как то, ИМХО, излишне. Сами потом утомитесь выдавать пользователям настолько тонко «нарезанные» права. А tos, если верить man-странице, и так требует CAP_NET_ADMIN.

А так, вы сначала попробуйте поработать в такой системе, где на всё подряд наставлены разные capabilities и подумайте, нужны ли ещё. Ну, а чтобы было ещё веселее, не забудьте про SeLinux.

Каким образом переписать программу, чтобы вместо пользователя с uid=0 был другой пользователь, на основе capabilities? Пока, как я понимаю, никак…

в rsbac для таких целей есть аттрибут «fake root». если он выставлен для испольняемого файла программы, то эта программа думает что ее запустили с euid=0. даже если на самом деле запущена обычным юзером. очень удобная штука. хоть и костыль в какой-то мере :)

attr_set_file_dir FILE /bin/ping min_caps NET_RAW
attr_set_file_dir FILE /bin/ping fake_root_uid 3

и программе больше не нужны права root-a. и она не будет ругаться что ее запустили без euid=0

да с простым-то ping все понятно.

Речь-то идет о том, как запускать `ping -f'. Там в исходном коде проверка на uid…