Deseja evitar desligamentos acidentais, reinicialização, etc., aliasando comandos como desligamento

1

Estou tentando aliasar comandos como shutdown , reboot , etc. Estou ciente de que essa não é uma maneira infalível de bloquear o acesso, no entanto, isso é apenas para impedir a execução acidental.

Eu consultei o superusuário .com / perguntas / 244342 e todos os links fornecidos dentro dele.

Para alias, algo como sudo /sbin/shutdown , primeiro teria que usar alias sudo individualmente e, em seguida, /sbin/shutdown to echo 'Not allowed' .

No entanto, isso não parece funcionar, pois o sudo obviamente o executa na raiz. Portanto, o aliasing no .bashrc do usuário é inútil. Como eu resolvo meu problema? Eu não quero modificar nenhum atributo do sistema, como .bashrc do usuário root, etc.

    
por Utkarsh.K 08.11.2016 / 09:08

3 respostas

1

Como você observou corretamente, aliases de shell não são adequados para o seu propósito.

A maneira correta de evitar a execução acidental desses comandos com sudo é atualizar sua configuração de sudo (usando visudo ) e impedir o acesso completamente. Você pode designar um grupo cujos membros têm permissão para executar esses comandos com sudo e mais ninguém.

    
por 17.12.2017 / 20:16
1

Ok, então a abordagem ' correta ' é não dar a esses usuários sudo, mas parece que essa é uma daquelas situações que você não pode evitar dar aos usuários esse acesso (Vamos digamos que você os impediu de executar o desligamento, eles podem apenas rm -rf /* )

No entanto, para impedi-los de executar comandos específicos via sudo, você pode controlá-lo no arquivo sudoers:

Primeiramente, definimos um alias para desligar um sistema em /etc/sudoers.conf

Cmnd_Alias SHUTDOWN = /usr/sbin/shutdown

E então removemos a capacidade de qualquer pessoa no grupo de rodas executar este comando:

%wheel ALL = ALL, !SHUTDOWN

Isso significa que todos os usuários podem executar todos os comandos em todas as máquinas, além daquelas no cmnd_Alias de desligamento.

man sudoers explicará isso com muito mais detalhes e, de fato, contém quase exatamente essa explicação. Observe também que isso não impediria que alguém deliberadamente tentasse executar o comando de desligamento, apenas aqueles que acidentalmente o executassem sem perceber (talvez porque estejam conectados à máquina errada).

    
por 17.12.2017 / 20:31
0

Mesmo que você consiga impedir que o usuário execute todos os comandos que são diretamente responsáveis por uma reinicialização, um usuário com sudo access (onde o acesso sudo não é lista de permissões para um conjunto específico de binários que eles não têm permissão para modificar, e que possivelmente não podem ser manipulados para executar o código de reinicialização) ainda pode reinicializar o sistema via:

  1. Faça o download do código-fonte para um programa como reboot ou halt (por exemplo, no GNU binutils, IIRC), compile-o usando gcc e execute sudo ./reboot em sua cópia local. >

  2. Escreva um programa em Ruby, Python, C / C ++, Java, etc. que chame os syscalls apropriados para iniciar uma reinicialização ou desligamento.

  3. Provavelmente, existem coisas complicadas que eles podem fazer com links simbólicos ou hardlinks para contornar uma lista negra. Essas coisas são sempre difíceis de lidar do ponto de vista da segurança, mas não tenho exemplos concretos do topo da minha cabeça.

Se você tem 100% de certeza de que todos os binários que você dá ao usuário a permissão para executar em sudo não podem ser manipulados para executar código arbitrário (o que leva aos itens 1 ou 2 acima), então talvez esteja tudo bem. Mas um usuário habilidoso (ou programa em execução como aquele usuário) ainda pode explorar vulnerabilidades de segurança em qualquer um desses programas para elevar e reinicializar / desligar.

Se você tiver certeza absoluta de que todos os usuários com sudo access cooperarão com você e não tentarão fazer coisas que não podem fazer, a lista negra deverá ser adequada para evitar "acidentes". Mas então você deve estar preparado para aceitar as conseqüências se alguém decidir se desviar da política por qualquer motivo.

Se você tiver dúvidas sobre os usuários, é melhor fornecer a cada usuário uma VM ou um contêiner seguro.

    
por 17.12.2017 / 22:35