Кажется, поддерживается поддержка мелкомасштабных возможностей в ядре Linux, что позволяет предоставлять привилегии процессу делать такие вещи, как, например, открытие сырых сокетов или повышение приоритета потока без предоставления привилегий root.
Однако, что я хотел бы знать, есть ли способ предоставить возможности для каждого пользователя. То есть разрешить процессы без полномочий root и non-suid получить эти возможности.
Там limits.conf, можно ограничить некоторые ресурсы для пользователя или группы через него.
Отъезд man limits.conf
Это может быть сделано с помощью libcap - он предоставляет модуль PAM pam_cap.so. Однако это не так просто:)
Каждый процесс имеет три набора возможностей:
Каждый файл имеет одинаковые наборы возможностей. Когда новый двоичный файл является exec() 'd, возможности процесса изменяются в соответствии со следующими правилами, где:
| представляет объединение
pI' = pI pP' = fP | (pI & fI) pE' = fE & pP'
(упрощенный из http://www.friedhoff.org/posixfilecaps.html)
В большинстве сценариев pE является единственным результатом, о котором мы заботимся. Программы, связанные с libcap, могут вызвать setcap(), чтобы изменить их Эффективные колпачки (если колпачки, которые они пытаются запросить, находятся в Разрешенном наборе), но подавляющее большинство программ явно не касаются своих кепок, поэтому мы должны установите, чтобы кепка была эффективной после-exec().
Наличие конкретного примера поможет понять здесь... Мне надоело "су" запускать openvpn, поэтому я хотел предоставить возможность CAP_NET_ADMIN разрешить настройку маршрутов и т.д.
Если посмотреть на последнее правило (pE' = fE & pP'), то ясно, что для CAP_NET_ADMIN в процессе Эффективный набор CAP_NET_ADMIN должен находиться в файле. Эффективный набор. Таким образом, система возможностей не позволяет просто сказать "предоставить CAP_NET_ADMIN пользователю sqweek" - возможности программы всегда важны.
Быть в файле Эффективный набор недостаточно, но в шапке также должен быть установлен новый разрешенный набор. Давайте посмотрим на это правило: pP' = fP | (pI & fI). Таким образом, есть два способа получить кепку в pP', либо добавим CAP_NET_ADMIN в файл Допустимый набор, либо добавим его в файл. Наследуемый набор и убедитесь, что он находится в процессе. Наследуемый набор.
Если мы добавим его в файл Разрешенный набор, то начальные возможности процесса станут неактуальными - openvpn будет получать CAP_NET_ADMIN каждый раз, когда он запускается, независимо от того, кто его запускает. Это похоже на setuid, но обеспечивает более тонкий подход. Тем не менее, это не зависит от каждого пользователя, поэтому давайте посмотрим на другой вариант.
Обратите внимание на первое правило, pI' = pI. Функция Inheritable не влияет на exec(). Это означает, что все, что нам нужно, - это единственная программа, поддерживающая libcap, для установки CAP_NET_ADMIN как шапки Inheritable, и каждый процесс, порожденный оттуда, также будет иметь CAP_NET_ADMIN Inheritable. Это роль, которую играет модуль pam - она изменяет набор Inheritable во время входа в систему, который затем наследуется для всех этих пользовательских процессов.
Подводя итог:
cap_net_admin sqweek в /etc/security/capability.conf. Если файл ранее не существовал, добавьте еще одну строку none * для разумного значения по умолчанию.auth required pam_cap.so в /etc/pam.d/login). Обязательно проверяйте свой логин в отдельном терминале ПЕРЕД записью при изменении PAM, чтобы вы не блокировали себя!setcap cap_net_admin+ie /usr/sbin/openvpn)openvpn вызывает ip, чтобы изменить таблицу маршрутизации и т.д., так что ей нужна такая же обработка (setcap cap_net_admin+ie /sbin/ip)Да, вы можете использовать setcap, чтобы указать набор возможностей для исполняемого файла, который может предоставлять определенные возможности при выполнении этого исполняемого файла.
Из возможностей (7) man page:
Возможности файлаПоскольку ядро 2.6.24, ядро поддерживает связывание наборы возможностей с исполняемым файлом файл с помощью setcap (8). Файл наборы возможностей хранятся в расширенный атрибут (см. setxattr (2)) с именем security.capability. Письмо в этот расширенный атрибут требует Возможность CAP_SETFCAP. Файл наборов возможностей в сочетании с наборы возможностей потока, определить возможности потока после выполнения execve (2).
Способ предоставления возможностей для каждого пользователя (или даже для каждой группы) был бы с модулем PAM. ответ sqweek показывает, как это сделать, используя pam_cap.
Я не подтвердил, но я думаю, что этот аспект SELinux может быть вашим ответом:
http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html#userpol5.1
Посмотрите CapOver - он должен делать то, что вы хотите.
Примечание. Я не использовал это, так как он (пока?) был перенесен в API ядра 2.6.30ish.