A concessão de um comando de atualização automática para usuários não-sudo é segura?

Question

Descobri que dou obtenha um acesso de usuário não-sudo a certos comandos com os privilégios de sudo . No entanto, meu plano para permita que eles executem apt-get dist-upgrade o sistema não é seguro porque eles podem acessar o shell como root. Então eu descobri que Eu posso manualmente invocar upgrades automáticos executando sudo unattended-upgrade -d .

Pergunta

Daria a um usuário não-root acesso para chamar unattended-upgrade ser seguro (por exemplo, não é possível entrar em um shell raiz)? Haverá outras conseqüências além do fato de que isso só instala atualizações de segurança (por exemplo, pacotes semi-instalados, etc.).

    

Answer 1

Solução

1. Criar um novo grupo: groupadd -r updaters A opção -r reserva um grupo de sistemas, por exemplo, de 0 a 100.
2. Adicionar usuários ao grupo acima: useradd -G updaters john , useradd -G updaters sally . Você também pode usar a seção de alias do usuário para obter isso . Consulte os Exemplos de arquivos Sudoer para obter uma seção de alias do usuário totalmente funcional. Na minha opinião, fazer da maneira que fiz adiciona segurança, já que o grupo realmente existe no sistema.
3. Crie sua lista de comandos para atualizadores: Nota: O Apt-get usa a passagem de argumentos. Veja a seção de problemas Cmnd_Alias UPDATE_CMDS = /usr/bin/aptitude, /usr/bin/dpkg, /usr/bin/apt-get up*, /usr/bin/apt-get install
   • Observe que dpkg é necessário para apt-get . Veja AskUbuntu: Adicionando o arquivo apt-get to sudoers .
   • Observe que apt-get update e apt-get upgrade são necessários. Usar um padrão glob alcança ambos.
   • Observe que aptitude pode ser usado para substituir apt-get se o comportamento dpkg indicado acima for indesejado. Se você não quiser que os usuários do grupo updaters sejam instalados na Internet com um clique do mouse ...

Agora, precisamos adicionar nossas atualizações ao nosso arquivo sudoers. Problema: visudo e:

O arquivo sudoers padrão do Ubuntu (com acréscimos de cima):

# /etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
#

Defaults    env_reset

# Uncomment to allow members of group sudo to not need a password
# %sudo ALL=NOPASSWD: ALL

# Host alias specification

# User alias specification

# Cmnd alias specification
Cmnd_Alias UPDATE_CMDS = /usr/bin/aptitude, /usr/bin/dpkg, /usr/bin/apt-get up*, /usr/bin/apt-get install

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

# Members of the upgraders group may perform certain upgrade commands.
# If No Password is desired, comment the line below, and see the next option.
%upgraders ALL=UPDATE_CMDS

# Members of the upgraders group may perform certain upgrade commands, 
# WITHOUT A PASSWORD DANGEROUS (uncomment if desired):
#%upgraders ALL=NOPASSWD:UPDATE_CMDS

Se você decidir adicionar unattended-upgrade , leia a Documentação Debian nela . e use which unattended-upgrade para determinar o caminho para adicioná-lo a UPDATE_CMDS . Veja Seção do problema .

Atualizar

Depois de mais pesquisas, eu encontrei um Blogpost: Everything você precisa saber sobre conffiles: arquivos de configuração gerenciados pelo dpkg . O problema não está nas variantes apt, o problema está na implementação dpkg subjacente. Citando:

Avoiding the conffile prompt

Every time that dpkg must install a new conffile that you have modified (and a removed file is only a particular case of a modified file in dpkg’s eyes), it will stop the upgrade and wait your answer. This can be particularly annoying for major upgrades. That’s why you can give predefined answers to dpkg with the help of multiple --force-conf* options:

• --force-confold: do not modify the current configuration file, the new version is installed with a .dpkg-dist suffix. With this option alone, even configuration files that you have not modified are left untouched. You need to combine it with --force-confdef to let dpkg overwrite configuration files that you have not modified.
• --force-confnew: always install the new version of the configuration file, the current version is kept in a file with the .dpkg-old suffix.
• --force-confdef: ask dpkg to decide alone when it can and prompt otherwise. This is the default behavior of dpkg and this option is mainly useful in combination with --force-confold.
• --force-confmiss: ask dpkg to install the configuration file if it’s currently missing (for example because you have removed the file by mistake).

Sabendo disso, como o blog aponta, podemos criar /etc/apt/apt.conf.d/local e adicionar (exemplo):

Dpkg::Options {
   "--force-confdef";
   "--force-confold";
}

Isso deve ignorar a opção Z todos juntos.

Problema

Upgrades autônomos geralmente são uma má ideia, porque o sistema operacional pode instalar itens inesperados, por exemplo, novos kernels ou drivers atualizados que quebrarão um driver em funcionamento, além da ideia de que você está dando a opção a um usuário . A outra questão aqui é que, como apt-get usa a passagem de argumentos para decidir qual opção executar, é necessário passar cada opção desejada no Alias de Comando criado. Adicionando cada argumento separadamente, removemos a capacidade de usar o argumento dist-upgrade . Como você, presumi que não se poderia passar um argumento no arquivo sudoers e, ao pesquisar também eu, aprendi algo novo.

Referências

nixCraft - Howto: Linux Adicionar usuário ao grupo
Aptidão - Documentação do Ubuntu
Fóruns do Ubuntu - Tópico: HowTO: Configuração de Sudoers
Documentação do Ubuntu - Instalando o software
AskUbuntu - Qual é a diferença entre apt-get atualizar e atualizar?