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:

• http://www.sudo.ws/man/1.8.12/sudoers.ldap.man.html

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:


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:


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