Por que a opção NOPASSWD do sudoers não está funcionando?


75

Eu tenho uma linha NOPASSWD em / etc / sudoers (editada com visudo)

gatoatigrado    ALL=(ALL) NOPASSWD: /bin/set-slow-cpufreq

No entanto, a saída é,

gatoatigrado@coral:~> sudo -n /bin/set-slow-cpufreq
sudo: sorry, a password is required to run sudo

Esse tipo de comando funciona em uma máquina OpenSuSE, mas não no Ubuntu 11.10. O que estou fazendo errado?

Nota : Não consigo encontrar nenhuma mensagem de log do sistema relevante, por exemplo, via tail -f /var/log/syslog.

editar

Aqui está / etc / sudoers.

Defaults    env_reset

# things I've tried copying from an opensuse machine
Defaults always_set_home
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"

root    ALL=(ALL:ALL) ALL
gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq
%admin ALL=(ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

2
Você pode mostrar a íntegra sudoers, a ordem das regras não é irrelevante.
enzotib 31/01

Respostas:


117

Você deve colocar essa linha após a linha com a regra do sudogrupo, porque, como a sudoerspágina de manual afirma:

   When multiple entries match for a user, they are applied in order.
   Where there are multiple matches, the last match is used (which is not
   necessarily the most specific match).

5
como uma observação adicional, isso se aplica a usuários em vários grupos também: por exemplo, usuário está no grupo admin e group sudo se a regra para sudo for após admin , a regra para sudo substituirá a regra para admin para o usuário nos dois grupos.
Populus

2
Obrigado! Eu adicionei minha linha ao final de /etc/sudoerse agora funciona. Explicação completa aqui para pessoas que estão interessadas: techglimpse.com/ubuntu-sudoers-nopasswd-option-not-working
elimisteve

4

Idealmente, se você estiver personalizando os comandos que podem ser executados, sudofaça essas alterações em um arquivo separado em /etc/sudoers.d/vez de editar o sudoersarquivo diretamente. Você também deve sempre usar visudopara editar o (s) arquivo (s).

Exemplo: sudo visudo -f /etc/sudoers.d/slowcpu

Insira sua linha concedendo permissão: gatoatigrado ALL=NOPASSWD: /bin/set-slow-cpufreq

Em seguida, salve e saia e visudoavisará se você tiver algum erro de sintaxe.

Você pode executar sudo -lpara ver as permissões concedidas ao usuário, se algum dos NOPASSWDcomandos específicos do usuário aparecer ANTES de qualquer %groupyouarein ALL=(ALL) ALLcomando na saída, você será solicitado a fornecer sua senha.

Se você estiver criando muitos desses arquivos sudoers.d, talvez queira criá-los com o nome de usuário, para que sejam mais fáceis de visualizar. Lembre-se de que a ordem dos NOMES DE ARQUIVOS e das REGRAS dentro do arquivo é muito importante; o ÚLTIMO carregado carrega, seja MAIS ou MENOS permissivo do que as entradas anteriores.

Você pode controlar a ordem dos nomes de arquivos usando um prefixo de 00-99 ou aa / bb / cc, mas lembre-se de que, se você tiver QUALQUER arquivo que não possua prefixo numérico, eles serão carregados após os arquivos numerados, substituindo as configurações. Isso ocorre porque, dependendo das configurações de seu idioma, a "classificação lexical" usada pelo shell classifica os números primeiro e, em seguida, pode intercalar maiúsculas e minúsculas ao classificar em ordem "crescente".

Tente executar printf '%s\n' {{0..99},{A-Z},{a-z}} | sorte printf '%s\n' {{0..99},{A-Z},{a-z}} | LANG=C sortverifique se o seu idioma atual é impresso AaBbCcetc. ou ABCentão abcpara determinar qual o melhor prefixo de "última" letra a ser usado.


Eu concordo com isto. Algumas das lógicas na edição do arquivo / etc / sudoers pareciam contra-intuitivas - não consegui fazer com que o% wheel ALL = (ALL) NOPASSWD: ALL funcionasse da maneira como foi escrito nos sudoers até ler um post onde alguém disse #includedir A linha /etc/sudoers.d tinha que estar antes das outras linhas como% SUDO e% WHEEL. Quando coloquei o dir #include acima das outras permissões de grupo, eles começaram a trabalhar. Então, eu criei arquivos para cada grupo em /etc/sudoers.d/ numerados na mesma ordem em que estavam no arquivo sudoers, mas a raiz ALL = (ALL) ALL ainda precisava ser sudoers abaixo da linha #includedir. Esquisito.
AveryFreeman 27/11

Na verdade, acho que o includedir deve permanecer no final dos agressores. O que você provavelmente estava vendo é que um dos outros arquivos em seu sudoers.d estava desfazendo sua alteração. Você também pode ter uma linha mais abaixo no seu arquivo principal que estava restringindo o grupo de roda. Lembre-se de que sudoers é processado onde a última regra a ser aplicada a um comando ou grupo vence, portanto, ajuda mais específica, mas se um comando geral QUALQUER chegar no final e não tiver NOPASSWD, ele substituirá as exceções anteriores. É por isso que você deve ter suas regras em arquivos separados para que sejam processadas posteriormente.
dragon788

Acho que não, foi uma nova instalação do arch. Tudo o que fiz foi tentar descomentar essa linha. Mas isso é definitivamente uma boa coisa para verificar, obrigado.
AveryFreeman

Alguns sistemas não usam o wheel e, em vez disso, usam um grupo chamado sudo ou adm ou admin. Não me lembro do comportamento do Arch, mas você pode executar ide ver a quais grupos pertence.
dragon788

Arch usa roda.
AveryFreeman

4

Apenas corri para isso também.

Minha situação é que estou configurando um sistema remoto que será executado sem cabeça. Habilitei a criptografia de disco completo (caso contrário, um invasor com acesso físico pode fazer o que ele quiser). Quero autenticar apenas com a chave pub (desabilitarei a senha para que o esquema "tenha algo, saiba algo" seja uma senha). par de chaves protegido - o logon root é naturalmente desativado)

O instalador do Ubuntu solicita um usuário administrador não raiz que é adicionado ao grupo sudo. Eu me adicionei manualmente ao sudoersarquivo usando sudo visudo:

my_username ALL=(ALL:ALL) NOPASSWD:ALL

OBSERVAÇÃO Se você usar o nopasswd em seu laptop, sempre deverá bloquear o computador enquanto se afasta, caso contrário, um invasor casual poderá comprometer muito enquanto você estiver se levantando para colocar creme no café

Eu ainda estava tendo que me autenticar com senha.

A resposta do enzotib é a chave para o que está acontecendo. O grupo sudo aparece em sudoers após a entrada para o meu nome de usuário.

Em vez de mover minha entrada abaixo da linha sudo, simplesmente removi a linha que havia adicionado anteriormente e depois adicionei NOPASSWDà entrada para%sudo

Isso parece funcionar. Novamente, use apenas o nopasswd se você realmente precisar (no meu caso, era exatamente o que eu precisava, para a maioria dos usuários que exigem uma senha para a atividade sudo é melhor)

AVISO adicional: Sempre edite sudoers com visudo. (sudo visudo) Além disso, ter outra janela aberta alternada para o usuário root permite recuperar quaisquer erros que você possa cometer ao alterar o arquivo sudoers.


Nunca é uma boa idéia habilitar o NOPASSWD contra todos / todos os comandos, isso significa que qualquer pessoa que entre no seu sistema e consiga colocar um usuário no grupo sudo poderá fazer QUALQUER COISA MAU ao seu sistema MUITO rapidamente. Posso fazer isso facilmente com apenas alguns minutos de acesso usando um LiveCD ou enganando o usuário para executar um cmd chamado sudoque usa suas próprias permissões para adicionar outro usuário ao grupo sudo, além de executar o comando solicitado.
Dragon788

2
Não faça declarações gerais como esta. Em um sistema sem cabeça, não é desejável definir uma senha de login (com base em pares de chaves), habilitei a criptografia de disco completo para ter boa sorte com esse CD ao vivo. (que, a propósito, permitiria que você fizesse todo tipo de coisa divertida em um sistema não criptografado, independentemente do arquivo sudoers). Além disso, você não pode escrever em nenhum dos locais do meu PATH e não vou lhe dar shell para começar. a menos que eu confie em você para não tentar subverter o sistema. Sua preocupação com a segurança não é inválida, está simplesmente desatualizada e não é tão universalmente aplicável quanto você sugere.
jorfus

Para aqueles que não têm um entendimento profundo de segurança como você, esse tipo de recomendação é provavelmente melhor que a alternativa, mas concordo que não é o ideal.
dragon788

@ dragon788 É verdade que talvez possamos editar nossas respostas para ajudar usuários de todos os níveis a dar um passo em direção a uma melhor segurança. Adicionarei um aviso para habilitar a criptografia completa do disco para evitar comprometimentos quando um invasor tiver acesso físico e uma observação de que, se um usuário de laptop esquecer de bloquear seu computador em público, o sudo nopasswd poderá levar a um comprometimento rápido. (Embora eu gostaria de propor a criação de um bloqueio de cinco minutos e tela de bloqueio tecla rápida pode realmente levar a melhor segurança.)
jorfus

Excelente atualização, minha resposta não tem recomendações fortes além desses comentários aqui e, ironicamente, no trabalho, onde uso criptografia de disco completa, acabei ativando o NOPASSWD porque tenho uma senha muito segura que se torna difícil de digitar repetidamente e uso o xautolock para bloquear minha máquina após um curto período de inatividade.
dragon788

0

No sistema remoto, descarte a criptografia, mas deixe que tudo seja de propriedade de uma raiz, como no grupo de "Administradores" - que não é 0!
Você pode alterar #sudo -g Administrators aqueles que precisam de acesso total - não no sudo arquivo, mas no .loginperfil. Agora, qualquer script padrão pode ter acesso ao controle remoto como "root" e você pode proteger os arquivos que devem ser protegidos.
Outro "grupo" útil é o "Sandbox" com um diretório de login no cache do navegador e pode ler isso livremente e nada mais. Use o primeiro caractere em maiúscula.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.