Por que o sistema tem o /etc/sudoers.d? Como devo editar?

Question

Última vez, perguntei sobre o risco deles (em / etc / sudoers):

    user_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf
    %group_name ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf

Enquanto pensava sobre este problema, encontrei o diretório /etc/sudoers.d . Os arquivos no diretório devem ter funções semelhantes ao / etc / sudoers (o que significa que os scripts acima ainda são problemáticos, mesmo em /etc/sudoers.d), e no entanto um artigo dizia que não deveríamos usar o diretório porque não podemos usar visudo para editar arquivos nele. Ou seja, perdemos o direito de usar sudo se cometermos um erro no diretório.

Se isso for verdade, por que temos /etc/sudoers.d ? Ou temos uma boa maneira de editar arquivos em /etc/sudoers.d ?

    

Answer 1

As alterações feitas nos arquivos em /etc/sudoers.d permanecem no lugar se você atualizar o sistema. Isso pode impedir o bloqueio do usuário quando o sistema é atualizado. O Ubuntu tende a gostar desse comportamento. Outras distribuições também estão usando esse layout.

Tem sido minha experiência que as regras sobre arquivos neste diretório são mais soltas do que para /etc/sudoers . Isso incluiu:

• Os erros no arquivo não causaram a falha sudo . No entanto, o arquivo foi ignorado.
• As regras de permissão parecem menos rigorosas. Ele permite que o grupo aplicável ou outro leia o arquivo. Eu não acredito que isso foi possível com /etc/sudoers . As permissões de gravação devem ser restritas a root para manter a segurança. A versão atual do Ubuntu do sudo permite permissões de leitura para grupos ou outros. (Esse recurso permite que o acesso sudo seja auditado usando sem exigir acesso root.)

O comando visudo é padronizado apenas por /etc/sudoers . Ele irá editar e verificar qualquer arquivo que você especificar com a opção -f . Eu uso esse recurso para editar arquivos que serão instalados automaticamente como /etc/sudoers ou em /etc/sudoders.d . No entanto, as definições de outros arquivos podem não ser encontradas. É melhor tornar o arquivo independente.

A capacidade de ter arquivos autônomos torna simples para um aplicativo habilitar o recurso sudo na instalação e removê-los quando não estiver instalado. Ferramentas de configuração automatizadas também podem usar esse recurso.

Eu usei esse recurso para isolar as alterações necessárias para conceder acesso a grupos de usuários específicos em sistemas específicos.

    

Answer 2

Sim, você pode usar visudo para editar esses arquivos. Tudo o que você precisa fazer é especificar o nome do arquivo que deseja editar com a opção -f . Por exemplo:

visudo -f /etc/sudoers.d/somefilename

Ou, se necessário:

sudo visudo -f /etc/sudoers.d/somefilename

Documentação

De man visudo :

-f sudoers
Specify and alternate sudoers file location. With this option visudo will edit (or check) the sudoers file of your choice, instead of the default, /etc/sudoers. The lock file used is the specified sudoers file with ".tmp" appended to it. In check-only mode only, the argument to -f may be "-", indicating that sudoers will be read from the standard input.

Em resumo:

1. Sintaxe: Tanto visudo como visudo -f executam a mesma verificação de sintaxe .

2. Permissões / Propriedade: Como um recurso adicionado para auxiliar a administração de sistemas grandes , os arquivos editados em visudo -f não são verificados quanto à propriedade ou permissões: isso permite a verificação da sintaxe de um arquivo offline ou como parte de um sistema de controle de revisão.

Por que usar /etc/sudoers.d/

Normalmente, /etc/sudoers está sob controle do gerenciador de pacotes de sua distribuição. Se você fez alterações nesse arquivo e o gerenciador de pacotes deseja atualizá-lo, será necessário inspecionar manualmente as alterações e aprovar como elas são mescladas na nova versão. Ao colocar as alterações locais em um arquivo no diretório /etc/sudoers.d/ , você evita essa etapa manual e as atualizações podem prosseguir automaticamente.

Quando o sudo ignora um arquivo em /etc/sudoers ?

Se o seu arquivo /etc/sudoers contiver a linha:

#includedir /etc/sudoers.d

então sudo lerá os arquivos no diretório /etc/sudoers.d .

As exceções são:

1. Arquivos cujos nomes terminam em ~
2. Arquivos cujos nomes contêm um caractere .

Isso é feito (a) para conveniência dos gerenciadores de pacotes e também (b) para que os arquivos de backup dos editores sejam ignorados.

    

Answer 3

why do we have /etc/sudoers.d?

Porque é mais fácil para ferramentas automatizadas (como Chef ou Puppet) colocar arquivos individuais nesse diretório, em vez de fazer alterações em /etc/sudoers , que podem ser frágeis.

Os arquivos em /etc/sudoers.d são (na verdade) concatenados. Você verá várias outras instâncias desse padrão em /etc , como /etc/cron.d e /etc/logrotate.d .

    

Answer 4

Outro benefício de usar visudo -f , como mencionado em algumas respostas, é que existe uma opção correspondente -c ou --check que verifica se você não tem informações inválidas em um arquivo sudoers.d ou em qualquer outro arquivo que você queira colocar em sudoers.d. Isto é REALMENTE acessível nos casos mencionados com ferramentas automatizadas, como você pode executar, e.

sudo visudo -c -q -f /home/myuser/mysudoers && \
sudo chmod 600 /home/myuser/mysudoers && \
sudo cp /home/myuser/mysudoers /etc/sudoers.d/mysudoers

Isso silenciosamente verifica o arquivo (sem saída devido a -q) e somente se isso NÃO retornar um erro (a saída 1 significa um arquivo sudoers inválido), então ele copiará o arquivo em sudoers.d, dessa maneira você pode criar o arquivo e trabalhe nele sem ter que acertar na primeira vez (usando sudo visudo -f /etc/sudoers.d/myfile tem que ter sucesso ou descarta o conteúdo se você não consertá-lo).

Além disso, uma palavra de cautela referente a essas declarações de outras respostas.

It has been my experience that the rules on files in this directory are looser than for /etc/sudoers. This has included:

Mistakes in the file did not cause sudo to fail. However, the file was ignored. Permission rules appear less strict. I allow the applicable group to read the file. I don't believe that is possible with /etc/sudo.

Os arquivos em /etc/sudoers.d são obrigados a aderir à mesma sintaxe que / etc / sudoers, porque sob as capas o sistema simplesmente concatena todos os arquivos com o último em "ganhar" se houver várias entradas para o mesmo cenário singular.

Se as permissões estiverem horrivelmente incorretas (graváveis pelo mundo) em arquivos em /etc/sudoers.d/, elas serão ignoradas, isso pode ter causado a falta de acesso aos arquivos inválidos; caso contrário, você poderá quebrar seriamente o comando sudo por ter um arquivo sudoers.d inválido com permissões corretas.

Você pode permitir que os arquivos sudoers sejam legíveis para o mundo, se você permitir acidentalmente 'outro' a permissão de gravação que você precisa sudo como outro usuário ou de um terminal raiz executar este comando. Isso também pode ser quebrado se o arquivo pertencer a alguém diferente de root: root.

sudo chmod 644 /etc/sudoers.d/mysudoers
sudo chown root:root /etc/sudoers.d/mysudoers

Acabei de confirmar que, se eu executar chmod o+w /etc/sudoers.d/vagrant , não consigo mais ser sudo como usuário vadio, ele solicita minha senha e falha.

Quando executei sudo -l para exibir as permissões de comando aplicadas como outro usuário sudo válido, também recebi um aviso sobre as permissões do arquivo. Este é o mesmo comando que eu usei para confirmar que o usuário 'vagrant' perdeu o sudo quando eu apliquei as permissões o+w ao arquivo, dando ao usuário permissões sudo.

    

Answer 5

Apenas um complemento curto para qualquer resposta geral ... nenhuma das outras respostas corrigiu o meu problema, o que era importante para a ordem.

Se suas linhas trabalharem em sudoers, mas não em sudoers.d, tente mover o #include ao redor ou altere a ordem dos arquivos sudoers.d (prefixando com um número). Parece que a coisa mais específica deve ser a primeira no arquivo.

Eu tinha algo como:

somebody ALL=(ALL): somecommand
somebody ALL=(someoneelse) NOPASSWD: somecommand

E o segundo não teve nenhum efeito porque o primeiro já correspondia. NOPASSWD não é uma condição, mas alguma maneira de modificar a ação.

E não era óbvio porque não estava em um único arquivo, devido ao diretório sudoers.d.