Use banco de dados para sudo

Question

Eu perguntei a uma pergunta semelhante hoje, sobre como autenticar meu servidor usuários para um banco de dados postgres em vez do arquivo /etc/passwd ou LDAP, e eu obtive algumas respostas úteis lá. Eu descobri que tenho três partes de minha autenticação de servidor para cuidar: registrar usuários, definir seus uid e gids e dar a eles sudo access, se necessário.

Consegui encontrar módulos NSS e PAM para postgres, mas não há informações sobre como usar um banco de dados, especialmente postgres, para sudo em vez de sudoers e sudoers.d . Eu tentei encontrar um plugin para o sudo, mas não parece que existe um - eu só encontrei o único plugin no site do sudo sudo página de plugins .

É possível usar um banco de dados externo para sudo ?

    

Answer 1

A maneira usual é tratar o sudo como ele é, um conjunto de arquivos de configuração. Administre-os através do gerenciamento de configuração que você escolheu, seja chef, fantoche, CFengine, subversion, git etc ou simplesmente edite-os manualmente.

Quando os privilégios / regras no sudo são dados aos grupos e não aos indivíduos, eles ficam bastante estáticos na minha experiência, a equipe de DBA precisa de su - oracle; su - sybase ; /etc/init.d/oracle * ; /etc/init.d/sybase * e quais mudanças são mais os membros da equipe de DBA.

Em seguida, seu gerenciamento de sudo é reduzido para gerenciamento de autenticação, usuário e grupo. É aí que o PAM aparece na foto novamente. Configure o PAM para usar um banco de dados de usuários gerenciado centralmente, seja LDAP, NIS, Active Directory (LDAP + Kerberos) ou até mesmo um banco de dados MySQL ou Postgresql. O sudo já usa o PAM por padrão.

Agora, basta gerenciar seu banco de dados de usuários / grupos com as ferramentas que funcionam melhor.

    

Answer 2

Se eu estivesse na sua posição, usaria o LDAP para resolver todos os três problemas:

1. Registro de usuários para entrada / saída (Autenticação).
   pam_ldap / nss_ldap , pam_ldapd ou qualquer número de outras opções existem aqui.
   Eles são todos bem comprovados e muito usados (o que significa que os fornecedores de sistemas operacionais garantem que eles funcionem), então por que não usá-los?

2. Definindo seu UID e GIDs (Atributos. Também como diretórios home, shell, etc ).
   Já resolvido pelas mesmas ferramentas que resolvem (1) - o diretório LDAP tem informações de usuário e grupo, graças ao esquema RFC 2307 extensões que praticamente todos os servidores LDAP suportam.

3. Dando às pessoas sudo (um caso especial de autorização).
   Sudo pode falar com um diretório LDAP e vem com uma especificação de esquema. Adicioná-lo ao seu diretório é trivial e as alterações são captadas instantaneamente.

Se você tem uma objeção religiosa ao LDAP e insiste em gerenciar essas informações em um banco de dados SQL, você pode usar SQL como um back-end para o OpenLDAP , mas francamente eu acho que seria Doing It Wrong - os dados não são naturalmente "relacionais" e você não deveria tentar forçá-lo a ser. Se você quiser fazer isso porque já tem um investimento substancial em um repositório de usuários com suporte a SQL, convém considerar isso como uma etapa transitória para colocar esses usuários no LDAP e converter seus outros aplicativos para autenticar / autorizar em um diretório LDAP.

LDAP/RFC 2307 is a really good model for user account management (though by no means perfect - it has a few brain-dead choices I don't agree with).

As a bonus a whole bunch of other things speak LDAP natively (for example Microsoft's Active Directory is just LDAP with some extras hanging off it, and MS supports extending AD with the RFC 2307 schema ; Apache has auth modules which speak LDAP) so by using LDAP you're well on your way to single-sign-on, and can interoperate with Microsoft's products which is a nice capability to have.

Você tem duas outras opções, mas elas não são realmente atraentes IMHO:

1. Escreva um plugin sudo para consultar o banco de dados .
   Isso tem a vantagem de ser em tempo real, como usar o LDAP. Você precisaria ser um programador decente (ou ter um disponível), mas se você fosse escrever um plugin desse tipo, eu tenho certeza que você poderia abrir o código e encontrar algumas pessoas dispostas a ajudar no desenvolvimento.

2. Armazene seus dados no banco de dados e sincronize os servidores com um cron job.
   Basicamente, gere um novo arquivo sudoers periodicamente - muito fácil de codificar, mas é definitivamente um hack deselegante. O fato de que as atualizações não ocorrem em tempo real significa que não é uma opção inicial em muitos ambientes.