Я был вдохновлен, чтобы снова начать играть с возможностями Linux, мой любимый проект - заменить setuid во многих двоичных файлах и предоставить доступ к дополнительным привилегированным утилитам для пользователей без прав root. Делаю это, добавляя соответствующие возможности ( +ei, проблема спорна с +ep) через setcapи настраиваю свою личную учетную запись пользователя ( jdavis4) так, чтобы эти возможности были назначены ее сеансу при входе в систему через pam_cap.soи все идет отлично. Я могу предоставить отдельным пользователям доступ к "ping" и "kill" через capabilities.conf
Проблема, с которой я столкнулся, заключается в том, что мне пришло в голову, что если бы это была производственная система, администратор, вероятно, захотел бы назначать возможности по какой-то совокупной единице, чтобы не делать этого для каждого отдельного пользователя каждый раз, когда они его создают. Таким образом, пользователь может быть просто добавлен в группу "filesystemAdmin" и получить что-то вроде CAP_DAC_OVERRIDEили добавлен в "ProcessManagement" и получить что-то вроде CAP_SYS_NICEи CAP_SYS_KILL.
Возможно ли это в настоящее время?
решение1
Мы добавили @groupсинтаксис для поддержки pam_cap.sos capability.confв libcap-2.29. На момент написания статьиlibcapнаходится в версии 2.49.
Также имеется некоторая документация дляpam_cap.so здесь.
решение2
То, что вы хотите сделать, невозможно. Он не только pam_capманипулирует только наследуемыми возможностями (поэтому он фактически не предоставляет никаких разрешенных/эффективных возможностей вообще), но и имеет дело только с пользователями, а не с группами (даже не с основными группами).
решение3
Я не могу найти документацию, в которой говорилось бы, что capacity.conf можно назначить непосредственно группе.
Похоже, это результат необходимости pam_cap «лишить» привилегий процесс аутентификации, который, вероятно, имеет «все» возможности или достаточно, чтобы стать таковыми. Это создает склонность, при которой кажется неразумным иметь кумулятивные аддитивные отображения, поскольку это может быстро стать «непроверяемой структурой». Таким образом, назначения через capabilities.conf не являются кумулятивными. Если вы находите соответствие, это то, что вы получаете. Ни больше, ни меньше.
С учетом сказанного:
можно настроить pam_cap для загрузки возможностей из произвольного файла в формате /etc/security/capability.conf
можно использовать скрипты в конфигурации pam. Было бы довольно просто сгенерировать файл capabilities.conf для каждого пользователя, проходящего аутентификацию, на основе его членства в группах и передать его модулю pam_cap.
Это не «элегантно» и не «идеально», но для большой базы пользователей типа LDAP это, вероятно, более проверяемо, чем «синхронизация через Jellyware уровня 8» между действительными пользователями и полнотекстовая запись для каждого пользователя в одном файле /etc/security/capability.conf.