Quando o Ubuntu pede a senha de um usuário administrador, como ele decide qual usuário administrativo solicitar?

Estou configurando uma máquina Ubuntu (10.10) que será usada por várias pessoas. É uma máquina compartilhada em um pequeno escritório. Suas principais funções são hospedar máquinas virtuais com o VirtualBox e servir arquivos com o Samba.

Para o Samba, várias contas de usuário precisam ser configuradas para que várias pessoas possam se conectar aos compartilhamentos do Samba em suas próprias estações de trabalho. No entanto, há também uma conta dedicada apenas à execução de máquinas virtuais, que várias pessoas estarão usando. Às vezes, as pessoas tentam fazer coisas com esta conta que exigem privilégios elevados - isso faz com que a caixa de diálogo "digite a senha do usuário administrativo" do Gnome seja exibida. No entanto, essa caixa de diálogo solicita minha senha - quando configurei a máquina, a minha foi a primeira conta criada, portanto, parece que estou assumindo que eu sou o único usuário com poderes de sudo concedidos.

Quero designar outro usuário como o "administrador do primeiro recurso", por assim dizer, e não pode ser o usuário da conta compartilhada, porque todo mundo precisa saber a senha dessa conta, por isso quero seus privilégios estritamente limitados. Não pode ser minha conta, pois de maneira nenhuma digo a outras pessoas minha senha e não estarei presente no site com frequência suficiente para inseri-la. Existe, porém, alguém que pode fazer isso pessoalmente, então eu os adicionei /etc/sudoers. Como posso dizer ao Ubuntu que, quando precisar elevar privilégios para alguma coisa, ele deve solicitar sua conta primeiro?

Para resumir:

• Contas na máquina: Alice, Bob, Carol, Dave, Eliza.
• Quando o Ubuntu foi instalado, Alice foi o primeiro usuário, adicionado durante o processo de instalação.
• "Dave" é na verdade uma conta que muitas pessoas usam, que não podem estar /etc/sudoersporque sua senha é de conhecimento público.
• Bob foi definido como uma conta "Administrativa" no Gnome e foi inserido corretamente /etc/sudoers- Bob é o chefe deste escritório.
• Quando ações que precisam de privilégios elevados são tentadas enquanto você está conectado como Bob, Carol, Eliza ou Dave, o sistema deve solicitar as credenciais de Bob.
• Quando ações que precisam de privilégios elevados são tentadas enquanto você está logado como Alice, o sistema deve solicitar as credenciais de Alice (embora Alice seja uma espécie de administrador de sistema do buckaroo e tenha o hábito de usar su -para executar tarefas administrativas ampliadas).

Quais alterações na configuração eu preciso fazer para obter o estado desejado aqui?

Antes de tudo, deixe-nos salientar que ações privilegiadas são permitidas para um usuário não root através de dois mecanismos diferentes.

1. sudo

2. PolicyKit

O primeiro é usado quando você executa explicitamente um comando sudoou um item de menu cujo comando é empacotado gksu(como o Synaptic Package Manager ).
Nesse caso, a senha necessária é a do usuário que está chamando, geralmente o usuário conectado.

O segundo é usado quando um aplicativo que reconhece o PolicyKit tenta executar uma ação privilegiada. Nesse caso, o aplicativo pergunta à autoridade local do PolicyKit (por meio do D-Bus) se a ação pode ser executada. A Autoridade Local, por meio de um Agente de Autenticação, solicita que o usuário ativo prove sua identidade. As janelas de diálogo são as seguintes (infelizmente com texto em italiano :)

Você pode identificar o PolicyKit no pequeno triângulo preto e no rótulo Detalhes . Como você pode ver, se houver mais de um usuário no admingrupo, você pode escolher na lista qual usuário usar para autenticação.

Diante de tudo isso, o sudoPolicyKit e muito mais complicado, com relação às configurações que podem ser alcançadas: você pode configurar ações que podem ser executadas sem senha, executadas apenas por um usuário ou grupo específico, etc.

Chegando à sua pergunta, quando o mecanismo usado pelo aplicativo é PolicyKit, independentemente do usuário atualmente conectado, a senha necessária seria a de Bob ou Alice (os dois únicos usuários administrativos, se bem entendi), e você poderá alterar na lista qual usuário você deseja usar para autenticação.

Quando o mecanismo usado pelo aplicativo é sudo(para tarefas administrativas executadas por meio da GUI, isso está se tornando menos frequente), você não tem um meio imediato e simples de escolher o usuário para autenticação.

Claramente, sudoseria a primeira escolha para mim nesse caso. Os principais aparece ponto a ser que a maioria dos administradores (atuais) não usam /etc/sudoersao máximo 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 sudogrupo para o qual geralmente existe uma regra nas configurações do Ubuntu ( %sudo...). Isso, é claro, concede liberdade aos usuários respectivos e todo o poder da conta do superusuário.

Dado o seu comentário:

então eu os adicionei /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 escreveria as poucas ações às quais Bob deve ser limitado. De fato, foi o que fiz em um servidor que mantenho, para permitir que dois usuários reinicializem um convidado KVM específico em um host. Os scripts conteriam um hashbang com caminho absoluto para o intérprete (por exemplo, em #!/bin/dashvez de #!/usr/bin/env bash) e provavelmente serão executados com um shell usado em outro lugar para tarefas privilegiadas ( /bin/dashou /bin/sh). Essas são apenas precauções. Fora isso, eu me certificaria de codificar todos os caminhos absolutos para os binários e usar o menor número possível. Por exemplo, ao usar bash/ dasheu preferiria builtins sobre commands (consulte man bash). Você pode tornar isso sustentável, atribuindo a uma variável o caminho absoluto e consultando o programa com base nessa variável ($VIRSHem vez de /usr/bin/virsh). Se possível, verifique o código de qualquer script externo antes de chamá-lo. Especialmente se você precisar chamá-los em um contexto privilegiado. No meu caso, também confino os usuários a um diretório raiz específico e a um subsistema SSH específico, pois eles somente se conectam à máquina via sshdautenticação de chave pública e. Obviamente você não precisa disso.

Certifique-se de chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>impedir que qualquer pessoa, além de rootadequada, mexa nela. Também deve ter cuidado com setuide setgidpedaços habilitado em binários alvo ( findpode ser usado para identificá-los). Vamos supor, no momento em que seu script reside /usr/sbin/priv-action.

Agora edite seu /etc/sudoers. noexecpode ser usado para impedir outros binários além daqueles explicitamente permitidos. Na verdade, existem muitas configurações adicionais, não apenas as que estou descrevendo aqui. Portanto, certifique-se de consultar man sudoers.

Agora, prefiro nomear os usuários ( User_Alias) no meu sudoersarquivo, mas você também pode usar um Group_Alias( man sudoers) ou um grupo de sistema real (por exemplo %sudo):

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

e 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 bob(ou melhor, os usuários listados abaixo LIMITED_ADMINS) executar os comandos privilegiados por meio do script:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

Diferentemente das definições de alias anteriores, essa linha requer uma explicação. Então, vamos primeiro cavar as partes na linha "Especificação do usuário". Aqui man sudoersajuda:

A estrutura básica de uma especificação do usuário é who where = (as_whom) what.

Linha de exemplo (encontrada na maioria das configurações do Ubuntu):

root    ALL=(ALL) ALL

Isso indica que um usuário chamado root (use #0para vinculá-lo ao UID 0) pode, em todos os hosts, executar em qualquer contexto do usuário qualquer coisa, mas será solicitada sua senha (assumindo o comportamento padrão). Adicionar a NOPASSWDtag antes da última ALLtambém permitiria rootfazer o mesmo sem ser solicitada 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 que boboutros membros listados User_Alias LIMITED_ADMINSexecutassem (em todos os hosts, ALLé para isso) como usuário root(grupo implícito, mas poderia ser fornecido, veja man sudoers) os comandos dados no Cmnd_Alias PRIV_ACTION. Fica melhor. Ainda supondo que você escreva esse script, você pode permitir vários parâmetros, evitando assim a criação de vários scripts. /etc/sudoersaceita alegremente curingas semelhantes a shell para limitar as possibilidades de argumentos permitidos.

Eu sempre constatei que os administradores não usam sudoerso modo como devem ser usados, e é por isso que apreciei o "Hack" respectivo dos dois livros "Linux Server Hacks" e "Linux Server Hacks Volume Two", que me deram início com um uso mais sofisticado desta grande instalação.

Você pode criar todos os tipos de soluções complicadas - o que pode não ajudar exatamente o aspecto de segurança - para o seu caso em particular, mas depois de falar o vocabulário básico, /etc/sudoersvocê pode realizar feitos mágicos :)

Nota: lembre-se de que você também pode criar um novo arquivo abaixo, /etc/sudoers.d/se sentir vontade. Isso pressupõe que você /etc/sudoerscontém a linha:

#includedir /etc/sudoers.d

Há apenas um superusuário no Unix / Linux, seu nome é root, mas sudoers são usuários que podem se tornar root. Você deve usar grupos:

newgrp admins

e depois atribua os usuários a esse grupo:

chgrp alice admins

adicione o grupo admins ao arquivo de configuração do sudoers como se o grupo fosse um usuário.

Atualizar

Ou você pode adicionar qualquer usuário ao grupo de administradores:

chgrp alice admin