documentation.suse.com / Documentação do SUSE Linux Enterprise Desktop / Guia de Administração / Tarefas comuns / Conceitos básicos sobre o sudo
Aplica-se a SUSE Linux Enterprise Desktop 15 SP7

2 Conceitos básicos sobre o sudo

 

A execução de determinados comandos exige privilégios de root. No entanto, por questões de segurança e para evitar erros, não é recomendado efetuar login como root. Uma abordagem mais segura é efetuar login como usuário comum e, em seguida, utilizar o sudo para executar comandos com privilégios elevados.

No SUSE Linux Enterprise Desktop, o sudo é configurado para funcionar de modo parecido com o su. No entanto, o sudo oferece um mecanismo flexível que permite aos usuários executar comandos com privilégios de qualquer outro usuário. Isso pode ser usado para atribuir funções com privilégios específicos a determinados usuários e grupos. Por exemplo, é possível permitir que os membros do grupo users executem um comando com os privilégios do usuário wilber. É possível restringir ainda mais o acesso ao comando quando você não permite nenhuma opção de comando. Enquanto o su sempre requer senha de root para autenticação com PAM, o sudo pode ser configurado para autenticar com suas próprias credenciais. Isso significa que os usuários não precisam compartilhar a senha de root, o que reforça a segurança.

2.1 Uso básico do sudo

 

O capítulo a seguir apresenta uma introdução ao uso básico do sudo.

2.1.1 Executando um único comando

 

Como usuário comum, você pode executar qualquer comando como root inserindo sudo antes do comando. Isso solicitará que você forneça a senha de root. Se a autenticação for bem-sucedida, o comando será executado como root: 

> id -un1
tux
> sudo id -un
root's password:2
root
> id -un
tux3
> sudo id -un
4
root

1

O comando id -un imprime o nome de login do usuário atual.

2

A senha não aparece ao ser digitada, nem como texto sem criptografia nem como caracteres de mascaramento.

3

Apenas os comandos que começam com sudo são executados com privilégios elevados.

4

Os privilégios elevados são mantidos por um determinado período, portanto, você não precisa inserir a senha de root novamente.

Dica
Dica: Redirecionamento de E/S

Ao usar o sudo, o redirecionamento de E/S não funciona: 

> sudo echo s > /proc/sysrq-trigger
bash: /proc/sysrq-trigger: Permission denied
> sudo cat < /proc/1/maps
bash: /proc/1/maps: Permission denied

No exemplo acima, apenas os comandos echo e cat são executados com privilégios elevados. O redirecionamento é realizado pelo shell do usuário com os privilégios do usuário. Para realizar o redirecionamento com privilégios elevados, inicie um shell conforme explicado na Seção 2.1.2, “Iniciando um shell” ou use o utilitário dd: 

echo s | sudo dd of=/proc/sysrq-trigger
sudo dd if=/proc/1/maps | cat

2.1.2 Iniciando um shell

 

Nem sempre é prático usar o sudo toda vez para executar um comando com privilégios elevados. Embora você possa usar o comando sudo bash, é recomendável usar um dos mecanismos incorporados para iniciar um shell:

sudo -s (<command>)

Inicia um shell especificado pela variável de ambiente SHELL ou o shell padrão do usuário de destino. Se um comando for especificado, ele será passado para o shell (com a opção -c). Do contrário, o shell será executado no modo interativo. 

tux:~ > sudo -s
root's password:
root:/home/tux # exit
tux:~ >
sudo -i (<command>)

Semelhante a -s, mas inicia o shell como um shell de login. Isso significa que os arquivos de inicialização do shell (.profile etc.) são processados, e o diretório de trabalho atual é definido como o diretório pessoal do usuário de destino. 

tux:~ > sudo -i
root's password:
root:~ # exit
tux:~ >
Dica
Dica: Variáveis de ambiente

Por padrão, o sudo não propaga as variáveis de ambiente. É possível mudar esse comportamento com a opção env_reset (consulte Opções e flags úteis).

2.2 Configurando sudo

 

O sudo oferece uma ampla variedade de opções configuráveis.

Nota
Nota: Comando sudo bloqueado

Se você se bloqueou por engano fora do sudo, use su - e a senha de root para iniciar um shell de root. Para corrigir o erro, execute visudo.

Atenção
Atenção: As configurações de exemplo são apenas para fins de demonstração

As regras de exemplo descritas abaixo são estritamente para fins de demonstração. Use-as para entender a sintaxe geral dos arquivos de configuração do sudo. Não as utilize em configurações reais, pois elas não refletem a complexidade desses ambientes.

2.2.1 Melhores práticas de configuração do sudo

 

Antes de começar, veja a seguir algumas regras básicas para manter as configurações do sudo:

Sempre usar o visudo para editar arquivos de configuração do sudo

As alterações na configuração do sudo devem ser feitas usando o comando visudo. O visudo é uma ferramenta personalizada que permite editar os arquivos de configuração do sudo e executa verificações de sintaxe básicas, garantindo que a configuração permaneça intacta e funcional. Uma configuração do sudo inválida pode fazer com que o usuário seja bloqueado do próprio sistema.

Sempre criar configurações personalizadas em /etc/sudoers.d/

As configurações personalizadas devem residir em /etc/sudoers.d/ para serem extraídas pelo sudo. As definições nos arquivos de configuração personalizada têm prioridade sobre aquelas na configuração padrão em /etc/sudoers.

Sempre prestar atenção à ordem de leitura das configurações

Para garantir que as configurações personalizadas sejam lidas na ordem correta, use números como prefixo. Inclua zeros à esquerda para estabelecer a ordem de leitura dos arquivos. Por exemplo, 01_myfirstconfig é analisado antes de 10_myotherconfig. Se uma diretiva tiver sido definida em um arquivo que foi lido antes de outro arquivo que contém informações conflitantes, a diretiva que foi lida por último será aplicada.

Sempre usar nomes de arquivo descritivos

Use nomes de arquivo que indiquem o que o arquivo de configuração faz. Isso ajuda você a reconhecer a ação planejada da configuração do sudo.

2.2.2 Criar um arquivo de configuração específico do usuário

 

Crie um arquivo de configuração do sudo que permita a um usuário comum (tux) usar o comando useradd com sua própria senha, em vez da senha de root.

Exemplo 2.1: Criar um arquivo de configuração específico do usuário
 

  1. Como administrador do sistema (root), crie um arquivo de configuração personalizado que inclua as novas diretivas específicas do usuário iniciando o visudo. Use a numeração e um nome descritivo: 

      # visudo -f /etc/sudoers.d/02_usermanagement

  2. Crie uma regra que permita ao tux executar o binário /usr/sbin/useradd em todo o ambiente ao qual esta configuração do sudo será aplicada: 

      tux1 ALL2 = /usr/sbin/useradd3

    1

    Especifique o usuário ou grupo. Liste os usuários por nome ou #UID e os grupos por %GROUPNAME. Separe vários itens com vírgulas. Para negar entradas, use !.

    2

    Especifique um ou vários hosts (separados por vírgulas). Use nomes de host (completos e qualificados) ou endereços IP. Adicione ALL para impor essa configuração globalmente a todos os hosts. Use ! para negações.

    3

    Especifique um ou vários executáveis (separados por vírgulas). Ao especificá-los, lembre-se das seguintes regras:

    /usr/sbin/useradd

    Sem nenhuma opção adicional inserida, isso permite a execução de todos os comandos useradd possíveis.

    /usr/sbin/useradd -c

    Se você especificar claramente uma opção, ela será a única permitida. Nada mais estará disponível para o usuário indicado acima.

    /usr/sbin/useradd ""

    Esse procedimento apenas permitirá que o usuário invoque um simples useradd sem nenhuma opção.

    No exemplo acima, você talvez queira permitir todas as opções e os subcomandos ou limitá-los a alguns por motivos de segurança, mas proibir um usuário de especificar qualquer opção não faz sentido nesse contexto.

  3. Para permitir que o usuário insira a própria senha em vez da senha de root, adicione a seguinte linha: 

    Defaults:tux !targetpw

    Quando ativo, esse flag exige que o usuário insira a senha do usuário de destino, ou seja, root. Esse flag está habilitado por padrão em qualquer sistema SUSE Linux Enterprise Desktop. Para negá-lo, use ! para exigir que o usuário insira apenas a própria senha em vez da senha de root.

  4. Grave a configuração, saia do editor e abra um segundo shell para testar se o sudo está seguindo sua nova configuração.

2.2.3 Criar configurações personalizadas agrupando itens

 

Modifique a configuração do Exemplo 2.1, “Criar um arquivo de configuração específico do usuário” para que um grupo de usuários nomeados possa executar o comando useradd sem a necessidade da senha de root. Além disso, adicione usermod e userdel à lista de comandos disponíveis para esse grupo.

Exemplo 2.2: Criar configurações personalizadas agrupando itens
 

  1. Para modificar a configuração de exemplo, abra-a como administrador do sistema com o visudo: 

    # visudo /etc/sudoers.d/02_usermanagement

  2. Adicione outros usuários à regra em uma lista separada por vírgulas: 

    tux, wilber ALL = /usr/sbin/useradd

  3. Para permitir que os usuários relacionados executem uma lista de comandos, especifique os comandos como uma lista separada por vírgulas: 

    tux, wilber ALL = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel

  4. Para permitir que os usuários listados insiram a própria senha em vez da senha de root, adicione a seguinte linha: 

    Defaults:tux, wilber !targetpw

    Quando ativo, esse flag exige que os usuários listados insiram a senha do usuário de destino, ou seja, root. Esse flag está habilitado por padrão em qualquer sistema SUSE Linux Enterprise Desktop. Para negá-lo, use ! para exigir que os usuários listados insiram apenas a própria senha em vez da senha de root.

  5. Grave a configuração, saia do editor e abra um segundo shell para testar se o sudo está seguindo sua nova configuração.

2.2.4 Simplificar as configurações aplicando álias

 

Use álias para simplificar ainda mais a configuração personalizada do Exemplo 2.2, “Criar configurações personalizadas agrupando itens”. O agrupamento de itens ajuda até certo ponto, mas o uso de álias globais para usuários, comandos e hosts é a maneira mais eficiente de manter a configuração do sudo clara e simples.

O uso de álias e grupos em vez de listas é uma maneira muito melhor de administrar as mudanças na configuração. Se um usuário sair, basta removê-lo da declaração global User_Alias no arquivo de declaração do álias, em vez de vasculhar todos os arquivos de configuração personalizados separados. O mesmo procedimento se aplica a qualquer outro tipo de álias (Host_Alias, Cmnd_Alias e Runas_Alias).

Exemplo 2.3: Simplificar as configurações aplicando álias
 

  1. Crie um novo arquivo para armazenar suas definições de álias globais: 

    # visudo /etc/sudoers.d/01_aliases

  2. Adicione a seguinte linha para criar o álias TEAMLEADERS: 

    User_Alias    TEAMLEADERS = tux, wilber

  3. Adicione a seguinte linha para criar o álias USERMANAGEMENT: 

    Cmnd_Alias    USERMANAGEMENT = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel

  4. Grave suas mudanças e saia do visudo.

  5. Como administrador do sistema, inicie o visudo para editar o arquivo de configuração de exemplo: 

    # visudo -f /etc/sudoers.d/02_usermanagement

  6. Apague e substitua a regra anterior pela seguinte regra que usa os álias que você acabou de definir acima: 

    TEAMLEADERS ALL = USERMANAGEMENT

  7. Para permitir que todos os usuários definidos por User_Alias insiram a própria senha em vez da senha de root, adicione a seguinte linha: 

    Defaults:TEAMLEADERS !targetpw

  8. Grave a configuração, saia do editor e abra um segundo shell para testar se o sudo está seguindo sua nova configuração.

2.2.5 Sintaxe de configuração básica do sudoers

 

Os arquivos de configuração sudoers contêm dois tipos de opções: strings e flags. Enquanto as strings podem conter qualquer valor, os flags podem ser ON ou OFF. Veja a seguir as construções de sintaxe mais importantes para os arquivos de configuração sudoers: 

# Everything on a line after # is ignored 1
Defaults !insults # Disable the insults flag 2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl 3

1

Há duas exceções: #include e #includedir são comandos regulares.

2

Remova o caractere ! para definir o flag desejado como ON.

3

Consulte o Seção 2.2.6, “Regras básicas do sudoers”.

Opções e flags úteis
 
targetpw

Esse flag controla se o usuário que faz a chamada deve digitar a senha do usuário de destino (ON) (por exemplo root) ou do usuário que faz a chamada (OFF). 

Defaults targetpw # Turn targetpw flag ON
rootpw

Se definido, o sudo solicitará a senha de root. O padrão é OFF. 

Defaults !rootpw # Turn rootpw flag OFF
env_reset

Se definido, sudo constrói um ambiente mínimo com TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME e SUDO_*. Além disso, as variáveis listadas em env_keep serão importadas do ambiente de chamada. O padrão é ON. 

Defaults env_reset # Turn env_reset flag ON
env_keep

Lista de variáveis de ambiente para manter quando o flag env_reset é ON. 

# Set env_keep to contain EDITOR and PROMPT
Defaults env_keep = "EDITOR PROMPT"
Defaults env_keep += "JRE_HOME" # Add JRE_HOME
Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME
env_delete

Lista de variáveis de ambiente para remover quando o flag env_reset é OFF. 

# Set env_delete to contain EDITOR and PROMPT
Defaults env_delete = "EDITOR PROMPT"
Defaults env_delete += "JRE_HOME" # Add JRE_HOME
Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME

É possível também usar o token Defaults para criar álias para uma coleção de usuários, hosts e comandos. Além disso, é possível aplicar uma opção apenas a um conjunto específico de usuários.

Para obter informações detalhadas sobre os arquivos de configuração sudoers, consulte man 5 sudoers.

2.2.6 Regras básicas do sudoers

 

Cada regra segue o esquema abaixo ([] marca as partes opcionais): 

#Who      Where         As whom      Tag                What
User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
Sintaxe da regra do sudoers
 
User_List

Um ou vários identificadores (separados por vírgula): um nome de usuário, um grupo no formato %GROUPNAME ou um ID de usuário no formato #UID. A negação pode ser especificada com o prefixo !.

Host_List

Um ou vários identificadores (separados por vírgula): um nome (completo) do host ou um endereço IP. A negação pode ser especificada com o prefixo !. ALL é uma opção comum para Host_List.

NOPASSWD:|PASSWD:

Não é solicitada uma senha para o usuário ao executar comandos correspondentes a Cmd_List após NOPASSWD:.

PASSWD é o padrão. Ele precisa ser especificado apenas quando ambos PASSWD e NOPASSWD estão na mesma linha: 

tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar
Cmnd_List

Um ou vários especificadores (separados por vírgula): um caminho para um executável, seguido de um argumento opcional permitido. 

/usr/bin/foo     # Anything allowed
/usr/bin/foo bar # Only "/usr/bin/foo bar" allowed
/usr/bin/foo ""  # No arguments allowed

ALL pode ser usado como User_List, Host_List e Cmnd_List.

Uma regra que permite que o tux execute todos os comandos como root sem digitar uma senha: 

tux ALL = NOPASSWD: ALL

Uma regra que permite que o tux execute systemctl restart apache2: 

tux ALL = /usr/bin/systemctl restart apache2

Uma regra que permite que o tux execute wall como admin sem argumentos: 

tux ALL = (admin) /usr/bin/wall ""
Atenção
Atenção: Regras não seguras

Não use regras como ALL ALL = ALL sem Defaults targetpw. Do contrário, qualquer pessoa pode executar comandos como root.

Importante
Importante: Winbind e sudo

Ao especificar o nome do grupo no arquivo sudoers, use o nome do domínio NetBIOS em vez do domínio Kerberos, por exemplo: 

%DOMAIN\\GROUP_NAME ALL = (ALL) ALL

Ao usar o winbindd, lembre-se de que o formato também depende da opção winbind separator no arquivo smb.conf. O padrão é \. Por exemplo, se ele for mudado para +, o formato da conta no arquivo sudoers deverá ser DOMAIN+GROUP_NAME.

2.3 Usando o sudo com aplicativos X.Org

 

Normalmente, ocorre o seguinte erro ao iniciar aplicativos gráficos com sudo: 

> sudo xterm
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set

Uma solução alternativa simples é usar o xhost para permitir temporariamente que o usuário root acesse a sessão X do usuário local. Para fazer isso, execute o seguinte comando: 

xhost si:localuser:root

O comando a seguir remove o acesso concedido: 

xhost -si:localuser:root
Atenção
Atenção: Possível problema de segurança

A execução de aplicativos gráficos com privilégios de root tem implicações de segurança. É recomendável habilitar o acesso de root para um aplicativo gráfico apenas como uma exceção. Também é recomendável revogar o acesso de root concedido logo após fechar o aplicativo gráfico.

2.4 Mais informações

 

O comando sudo --help oferece uma breve visão geral das opções de linha de comando disponíveis. O comando man sudoers fornece informações detalhadas sobre o sudoers e sua configuração.