Fui inspirado a começar a brincar com os recursos do Linux novamente. Meu projeto favorito é substituir o setuid em muitos binários e fornecer acesso a utilitários privilegiados adicionais para usuários não-root. Fazendo isso adicionando os recursos relevantes ( +ei, o problema é discutível com +ep) via setcape configurando minha conta de usuário pessoal ( jdavis4) para que esses recursos sejam atribuídos à sua sessão no login via pam_cap.soe está indo muito bem. Posso conceder a usuários individuais acesso a "ping" e "kill" viacapacity.conf
O problema que estou tendo, porém, é que me ocorreu que se este fosse um sistema de produção, um administrador provavelmente iria querer atribuir capacidades por algum tipo de unidade agregada para que eles não tivessem que fazer isso para cada usuário individual toda vez que eles fazem um. Dessa forma, um usuário pode simplesmente ser adicionado ao grupo "filesystemAdmin" e obter coisas como CAP_DAC_OVERRIDEou adicionadas a "ProcessManagement" e obter coisas como CAP_SYS_NICEe CAP_SYS_KILL.
Isso é possível atualmente?
Responder1
Adicionamos @groupsintaxe ao pam_cap.sosuporte capability.confno libcap-2.29. No momento da escrita,libcapestá na versão 2.49.
Há também alguma documentação parapam_cap.so aqui.
Responder2
O que você quer fazer não é possível. Não apenas pam_capmanipula os recursos herdáveis (portanto, na verdade, não concede nenhum recurso permitido/efetivo), mas também lida apenas com usuários e não com grupos (nem mesmo com grupos primários).
Responder3
Não há nenhuma documentação que possa encontrar para afirmar que o arquivocapacity.conf possa ser atribuído diretamente a um grupo.
Isto parece ser um produto da necessidade do pam_cap 'retirar' os privilégios do processo de autenticação, que provavelmente tem capacidade 'toda', ou o suficiente para se tornar tal. Isto cria uma propensão para que pareça imprudente ter mapeamentos aditivos cumulativos, uma vez que poderia rapidamente tornar-se uma “estrutura inverificável”. Portanto, as atribuições por meio decapacity.conf não são cumulativas. Se você acertar um fósforo, é isso que você ganha. Nem mais nem menos.
Com isso dito:
é possível configurar o pam_cap para carregar recursos de um arquivo arbitrário no formato /etc/security/capability.conf
é possível usar scripts dentro de uma configuração pam. Seria razoavelmente trivial gerar um arquivocapacity.conf por usuário para o usuário autenticador, com base em suas associações de grupo e alimentá-lo no módulo pam_cap.
Não é 'elegante' ou 'ideal', mas para uma grande base de usuários do tipo ldap-ish é provavelmente mais verificável do que 'sincronizar através de jellyware da camada 8' entre usuários válidos e uma entrada de texto completo por usuário em um único /etc /security/capability.conf.