Sudoers 1.8.12 - Parte I - Manual

Série de artigos sobre segurança com sudo. Essa é primeira parte do manual de SUDOERS.

[ Hits: 3.942 ]

Por: Perfil removido em 09/09/2015


Descrição



O plug-in sudoers é responsável por definir a política padrão de segurança na elevação de privilégios para os usuários de sudo. Este é plug-in padrão. A política é conduzida pelas definições declaradas no arquivo /etc/sudoers ou por configurações de LDAP. O formato da política é descrito em detalhes na seção "formato do arquivo sudoers". Para informações sobre como criar uma política sudo com LDAP consulte:

Configurando sudo.conf para sudoers

Sudo consulta o arquivo sudo.conf(5) para determinar quais as políticas e os plug-ins de I/O são carregados. Se não há um sudo.conf presente, ou se ele não contém informações sobre quais plug-ins de I/O carregar, sudoers será utilizado para todas as decisões e controlará o log de I/O. Para configurar explicitamente sudo.conf para usar um plug-in sudoers, a seguinte declaração é utilizada:

Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so

A partir de sudo 1.8.5, é possível especificar argumentos opcionais para os plug-ins de sudoers em sudo.conf. Esses argumentos, se presentes, devem ser listados após o caminho (path) do plug-in (no exemplo, após sudoers.so). Múltiplos argumentos podem ser definidos desde que separados por espaço em branco. Por exemplo:

Plugin sudoers_policy sudoers.so sudoers_mode=0400

Os seguintes argumentos são suportados:
  • ldap_conf=pathname - Sobrescreve o caminho padrão para o arquivo ldap.conf.
  • ldap_secret=pathname - Sobrescreve o caminho padrão para o arquivo ldap.secret.
  • sudoers_file=pathname - Sobrescreve o caminho padrão para o arquivo sudoers.
  • sudoers_uid=uid - Sobrescreve o valor do UID declarado em sudoers. Apenas valores numéricos são aceitos como UID.
  • sudoers_gid=gid - Sobrescreve o grupo padrão em sudoers. Apenas valores numéricos são aceitos como GID.
  • sudoers_mode=mode - Sobrescreve o modo (permissão) padrão definido em sudoers. Deve ser especificado como um valor em octal. Consulte o manual sudo.conf(5) para mais informações.

Autenticação e Registro de Log

A política de segurança sudoers requer que a maioria dos usuários se autentiquem antes de usar sudo. Se o usuário em questão for root, nenhuma senha será requerida. Se o usuário-alvo for o mesmo usuário que estiver invocando, ou se a política de autenticação estiver desativada para o usuário ou para o comando em questão, nenhuma senha é solicitada. Ao contrário de su (1), quando os sudoers requerem uma autenticação, eles estão invocando uma elevação de privilégios para si mesmos, e não as credenciais de outro usuário regular ou do próprio root. Esse comportamento padrão pode ser modificado com as opções: rootpw, targetpw e runaspw. Essas flags são descritas adiante.

Se um usuário que não estiver listado na política tenta executar um comando via sudo, um e-mail é enviado para os responsáveis pela política de segurança. A mensagem é enviada para os e-mails configurados (mailto) e para o root.

Nenhum e-mail de alerta será enviado se esse usuário apenas usar as opções -l ou -v, a menos que as flags relacionadas com erro de autenticação (mail_always ou mail_badpass) estejam ativas. Isso permite aos usuários testar se possuem ou não algum direito cadastrado em sudo. Todas as tentativas de elevação de privilégios com a execução de sudo (bem-sucedidas ou não) são registradas em log. Esse comportamento independe de envio ou não de mensagens via e-mail.

Se sudo é executado pelo root e a variável de ambiente SUDO_USER estiver definida, a política em sudoers usará esse valor para determinar quem de fato é o usuário. Isso pode ser utilizado mesmo que o usuário tenha invocado sudo através de um terminal administrativo. Isso também permite que a opção -e permaneça útil, mesmo quando sudo é executado através de um script ou um programa que gerencia elevações de privilégios. Observe, entretanto, que as ações dos sudoers ainda são feitas pela elevação de privilégios de root, e não com as credenciais ou direitos administrativos do usuário em SUDO_USER.

Os sudoers possuem um arquivo de cache, em uma base por usuário-sessão, baseado em uma estampa de tempo (per-user time stamp). Uma vez que esse usuário foi autenticado, um registro é escrito armazenando o UID da autenticação, o ID da sessão do terminal e a estampa de tempo. A estampa de tempo usa uma representação clock_monotonic (se disponível no sistema operacional) e não aceita modificações, pois não é um relógio real.

Esse cache de autenticação permite um tempo de graça, no qual o uso de sudo sem necessidade de nova autenticação é franqueado. O valor padrão é de 5 minutos. Por padrão, sudoers usa um arquivo de tempo para cada sessão de terminal (baseado em tty), isso significa que as sessões são autenticadas separadamente, mesmo que o usuário seja o mesmo em vários terminais.

Uma opção tty_tickets pode forçar o comportamento de uma única autenticação para todas as sessões de um usuário. Os registros de log de sudo são enviados para syslog, diretamente para um arquivo de log ou ambos. O padrão é usar um sistema de logs como syslogd para registrar as atividades de sudo. Também é possível para sudo registrar em log o fluxo (stream) de entradas e saídas. Por padrão, esse comportamento é desativado. Para alterar é preciso modificar o valor das flags em log_input e log_output.

Ambiente de Comando

Uma vez que as variáveis de ambiente podem influenciar o comportamento dos comandos ou programas, sudoers provê um modo de restringir quais variáveis de ambiente são herdadas quando o comando é executado. Existem dois modos distintos que os sudoers podem lidar com variáveis de ambiente:

Por padrão, a opção env_reset é ativada. Isso faz com que os comandos sejam executados com um ambiente novo e mínimo. Em AIX (e Linux sem PAM) o ambiente é inicializado com o conteúdo das definições do arquivo em /etc/environment. Em sistemas BSD, se a opção use_loginclass estiver ativa, o ambiente é inicializado baseado no path e valores de setenv definidos em /etc/login.conf. O novo ambiente contêm as seguintes variáveis: TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME e SUDO_*. Essas variáveis são adicionadas àquelas declaradas como argumento quando o comando foi invocado. Os valores em env_check e env_keep definem esse comportamento e funcionam como uma "lista branca" de variáveis de ambiente.

Variáveis cujo valor tenha () são removidas, a menos que o nome e o valor combinem com valores em env_check ou env_keep. Antigas versões do BASH podem interpretar esses nomes como funções (o manual não diz se isso é um problema ou uma coisa boa! Mas, creio que seja um problema que deva se evitado).

Versões anteriores a 1.8.11 sempre removem esse tipo de variável. Entretanto, se env_reset é desativada, qualquer variável que não for explicitamente negada em env_check ou env_delete são herdadas pelo processo do comando. Neste caso, env_delete e env_check funcionam como um tipo de "lista negra" de variáveis. Uma vez que é quase impossível criar uma lista negra completa, o uso de env_reset como comportamento padrão é encorajado.

Por padrão, variáveis de ambiente são combinadas apenas por nome. Todavia, se um sinal de igualdade (=) estiver envolvido, elas são avaliadas por nome e por conteúdo. Antes do bug shellshock do BASH, uma expressão como ( env_keep += "my_func=()*" ) era aceita.

A lista completa das variáveis de ambiente que sudo aceita ou nega pode ser obtida com a opção -V, quando executada por root. Observe que essa lista muda de acordo com o sistema operacional em uso, e sistemas que suportam PAM, desde que o módulo (variável?) pam_env estiver ativa para sudo.

As variáveis do ambiente PAM podem ser mescladas ao ambiente sudo. Se uma variável do ambiente PAM estiver presente no ambiente do usuário, o valor será sobrescrito se não houver previsão de sua preservação em sudoers. Quando env_reset está ativa, variáveis preservadas do ambiente do usuário que invocou sudo, baseadas em env_keep possuem precedência sobre variáveis de PAM.

Quando env_reset está desativado, variáveis presentes no ambiente do usuário que invocou tem precedência sobre as de PAM, a menos que elas combinem com o valor presente em env_delete.

Observe que as ligações dinâmicas, na maioria dos sistemas operacionais, removem as variáveis que podem controlar dinamicamente executáveis com setuid, isso incluí o próprio programa sudo. Variáveis do tipo:_RLD*, DYLD_*, LD_*, LDR_*, LIBPATH, SHLIB_PATH, e outras similares são removidas e não é possível para sudo preservá-las, mas isso depende do tipo de sistema operacional.

Um caso especial ocorre se a opção -i de sudo for definida, sudoers vão inicializar seu ambiente independentemente dos valores em env_reset. Os valores de DISPLAY, PATH e TERM permanecem inalterados; HOME, MAIL, SHELL, USER e LOGNAME são ajustados aos valores do usuário-alvo. Em AIX (e Linux sem PAM) os valores em /etc/environment são incluídos. Nos BSD os valores em /etc/login.conf são utilizados. Todas as demais variáveis são removidas. Finalmente, se a opção em env_file é definida, quaisquer variáveis presentes neste arquivo serão configuradas com seus respectivos valores, desde que, não conflitem com uma variável já existente.

Referências

[1] - http://www.sudo.ws/man/1.8.12/sudoers.man.html

   

Páginas do artigo
   1. Descrição
Outros artigos deste autor

Relato I Fórum da Revista Espírito Livre

Balanceamento de link + redundância

Kit de scripts para backup (Full + Diferencial + Samba + Rede)

Configurando o OpenOffice

Como prevenir o Buffer Overflow

Leitura recomendada

Bloqueio de usuários com página de aviso

Consegue guardar um segredo?

YASG (Yet Another Security Guide)

Automatizando as atualizações no Linux

Implementação de um sistema de arquivos criptografado transparente ao usuário

  
Comentários

Nenhum comentário foi encontrado.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts