Claramente, sudo seria a primeira escolha para mim em tal caso. O ponto principal parece ser que a maioria dos administradores (reais) realmente não usa /etc/sudoers em toda a extensão possível ( User_Alias , Runas_Alias , Host_Alias , Cmnd_Alias ).
A maioria dos administradores acaba usando apenas algumas das regras existentes e adicionando usuários, ou pior, simplesmente adicionando usuários ao grupo sudo para o qual uma regra normalmente existe nas configurações do Ubuntu ( %sudo ...) Isso, é claro, dá aos respectivos usuários liberdade total e o poder total da conta de superusuário.
Dado seu comentário:
, adicionei-os a /etc/sudoers
Eu acho que você também não o usa na medida do possível.
Em um cenário como o seu, eu literalmente escreverei as poucas ações às quais o Bob será limitado. Na verdade, foi isso que fiz em um servidor que mantenho, para permitir que dois usuários em particular reinicializem um determinado convidado KVM em um host. Os scripts conteriam um hashbang com caminho absoluto para o interpretador (por exemplo, #!/bin/dash em vez de #!/usr/bin/env bash ) e provavelmente seriam executados com um shell usado em outro lugar para tarefas privilegiadas ( /bin/dash ou /bin/sh ). Essas são apenas precauções. Fora isso, eu iria certificar-se de codificar todos os caminhos absolutos para binários e usar o menor número possível deles. Por exemplo. Ao usar bash / dash , prefiro builtin s acima de command s (consulte man bash ). Você pode tornar isso sustentável, atribuindo a variável o caminho absoluto e referindo-se ao programa com base nessa variável ( $VIRSH em vez de /usr/bin/virsh ). Se você puder, examine o código de qualquer script externo antes de chamá-los. Especialmente se você precisar chamá-los em um contexto privilegiado. No meu caso, eu também confino os usuários a um diretório raiz específico e a um subsistema SSH específico, pois eles só se conectam à máquina via sshd e autenticação de chave pública. Obviamente você não precisa disso.
Certifique-se de chown root: <the-script>; chmod u=rw,a=,a+rx <the-script> para evitar que alguém, a não ser root , mexa nele. Também tenha cuidado com setuid e setgid bits ativados nos binários de destino ( find pode ser usado para identificá-los). Vamos supor que o script esteja em /usr/sbin/priv-action .
Agora edite seu /etc/sudoers . noexec pode ser usado para prevenir outros binários do que aqueles explicitamente permitidos também. Na verdade, existem muitas configurações adicionais, não apenas aquelas que estou descrevendo aqui. Portanto, não deixe de consultar man sudoers .
Agora, prefiro nomear os usuários ( User_Alias ) no meu arquivo sudoers , mas você também pode usar um Group_Alias ( man sudoers ) ou um grupo de sistemas real (por exemplo, %sudo ):
# The list is comma-separated: bob,alice,...
User_Alias LIMITED_ADMINS=bob
e, em seguida, adicione um alias de comando para permitir a execução desse script específico:
# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias PRIV_ACTION=/usr/sbin/priv-action
Por último, mas não menos importante, vem a linha mágica para permitir que bob (ou melhor, os usuários listados em LIMITED_ADMINS ) executem os comandos privilegiados por meio do script:
LIMITED_ADMINS ALL=(root) PRIV_ACTION
Ao contrário das definições de alias anteriores, essa linha requer uma explicação. Então, vamos primeiro nos aprofundar nas partes em uma linha de "Especificação do Usuário". Aqui man sudoers ajuda:
A estrutura básica de uma especificação do usuário é who where = (as_whom) what .
Exemplo de linha (encontrada na maioria das configurações do Ubuntu):
root ALL=(ALL) ALL
Isso diz que um usuário chamado root (use #0 para vinculá-lo ao UID 0 ) pode, em todos os hosts, executar qualquer contexto de usuário, mas será solicitado para sua senha (assumindo o comportamento padrão). A adição da tag NOPASSWD antes do último ALL também permitiria que root fizesse o mesmo sem receber uma senha (assim: root ALL=(ALL) NOPASSWD:ALL ). ALL é um alias curinga intrínseco para os vários tipos de alias.
Mas voltando a Bob:
LIMITED_ADMINS ALL=(root) PRIV_ACTION
permitiria bob e outros membros listados do User_Alias LIMITED_ADMINS serem executados (em todos os hosts, para o qual o ALL é) como usuário root (grupo implícito, mas poderia ser fornecido, consulte man sudoers ) os comandos fornecidos no Cmnd_Alias PRIV_ACTION . Fica melhor. Ainda assumindo que você escreve este script, você poderia permitir vários parâmetros, evitando assim escrever vários scripts. /etc/sudoers aceita com prazer os curingas para limitar as possibilidades de argumentos passados.
Descobri consistentemente que os administradores não usam sudoers o modo como deve ser usado, e é por isso que apreciei o respectivo "Hack" dos dois livros "Linux Server Hacks" e "Linux Server Hacks Volume Two" , que me iniciou com um uso mais sofisticado desta grande facilidade.
Você pode inventar todos os tipos de soluções complicadas - que podem não ajudar exatamente no aspecto de segurança - para o seu caso em particular, mas uma vez que você fala o vocabulário básico de /etc/sudoers você pode realizar feitos bastante mágicos:)
NB: lembre-se de que você também pode criar um novo arquivo abaixo de /etc/sudoers.d/ se você se sentir inclinado. Isso pressupõe que /etc/sudoers contenha a linha:
#includedir /etc/sudoers.d
