Como configurar corretamente o arquivo sudoers, no debian wheezy?

Question

Eu vi muitos posts no blog que dizem que é suficiente para fazer

aptitude install sudo
su root
adduser USERNAME sudo

Mas isso protege apenas aptitude , em outras palavras:

• aptitude install sendmail pedirá senha, você precisa estar sudo para executar aptitude

• apt-get install sendmail não pedirá senha, sem sudo priviles necessário

• Se você editar arquivos protegidos, como arquivos em etc , não solicitará senha, sem sudo privilégios necessários

• Você pode executar e interromper serviços como apache , não solicitará senha, sem sudo privilégios necessários

Como consertar isso? Este é o meu arquivo sudoers:

 This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults        env_reset
Defaults        mail_badpass
Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:$

# Host alias specification

# User alias specification

# Cmnd alias specification

Esta é a saída de sudo -l :

Matching Defaults entries for root on this host:
    env_reset, mail_badpass,
    secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin

User root may run the following commands on this host:
    (ALL : ALL) ALL
    (ALL : ALL) ALL

    

Answer 1

Você não adicionou nenhuma regra sudo, então você não pode usar o sudo para nada.

O comando adduser USERNAME sudo adiciona o usuário especificado ao grupo chamado sudo . Um grupo com esse nome deve existir; crie-o com addgroup sudo se isso não acontecer. Depois de adicionar o usuário ao grupo, o usuário deve efetuar logout e voltar para que os membros do grupo entrem em vigor.

sudo não é um nome de grupo especial. É uma convenção permitir que usuários do grupo chamado sudo executem comandos como root através do utilitário sudo . Isso requer a seguinte linha no arquivo sudoers :

%sudo ALL = (ALL) ALL

Execute visudo para editar o arquivo sudoers, nunca edite-o diretamente.

Eu não tenho ideia de por que você acredita que "isso apenas protege a aptidão". Não há nada de especial sobre aptidão. Depois de autorizar um usuário a executar comandos como raiz, esse usuário pode executar sudo aptitude … ou sudo apt-get … ou sudo service … ou sudoedit para editar arquivos que precisam de permissão de raiz para editar. Estar no arquivo sudoers não altera diretamente os privilégios de seu usuário, o que ele faz é permitir que você execute sudo para executar comandos como root. Os comandos são executados como root somente quando você os executa por sudo . Alguns programas podem fazer isso automaticamente, especialmente programas GUI onde a interface do usuário é executada sem privilégios especiais e somente o backend é executado como root, mas os comandos executados como root são sempre executados por sudo .

    

Answer 2

O que pode ter acontecido é: sudo está armazenando sua senha em cache. Então, depois de ter completado corretamente a implementação do sudo no seu sistema, você tem que digitar a senha para o comando primeiro , e depois disso ele é armazenado em cache por algum tempo. Se isso acontecer e você executar a sequência

sudo aptitude install sendmail
sudo apt-get install sendmail

Então você terá que fornecer uma senha no primeiro comando, mas não no segundo (pelo menos enquanto você estiver dentro do tempo limite). Isso pode parecer como se estivesse protegendo apenas o primeiro comando, mas não o segundo. Sem mais informações (transcritos de shell completos), não há como saber ...

    

Answer 3

Se você seguir a resposta acima, você está indo no caminho certo. Pelo menos no Debian Jessie, eu criei um link para / usr / bin do comando no caminho / sbin. Por exemplo: / sbin / ifup, eu coloco um link (ln -s) para / usr / bin e eu posso usá-lo.

Outra coisa importante é colocar o NOPASSWD assim:

User_Alias NET = goviedo
Cmnd_Alias ETH = /sbin/ifup
NET ALL = NOPASSWD:ETH