Linux: desligamento não executável para segurança

Question

Hoje eu encerrei uma máquina de produção por engano porque achei que estava em minha máquina local. Eu sei, erro novato: - (

Como uma solução para que isso não aconteça novamente, eu estava pensando em remover a permissão de execução para o comando shutdown, já que a máquina deveria estar sempre ativa.

É uma boa ideia? Você consegue ver algum efeito colateral indesejado fazendo isso?

Felicidades, Dan

    

Answer 1

Completamente outra abordagem como ser avisado de que você trabalha na máquina de produção é marcar o terminal. Por exemplo, o user@machine:~# text poderia ser vermelho nas máquinas de produção, verde no desenvolvimento, etc. Aqui está um bom tutorial como fazer isso: Color Bash Prompt

    

Answer 2

O melhor conselho que posso dar é que você não faça o login como root, a menos que você precise de acesso root, e tenha certeza de ter uma senha root / sudo diferente em cada máquina.

Tornar o desligamento inacessível é uma opção, mas não é boa. Alias shutdown to shutdown -a e touch /etc/shutdown.allow ou chmod a-x /sbin/shutdown

Além disso, onde termina? Você também vai proibir interromper, reinicializar e iniciar?

    

Answer 3

Alguns pontos a considerar:

1. O que você estava fazendo como root em um sistema de produção durante o tempo de produção? Configure seus sistemas para que você não precise ser root neles para o trabalho do dia-a-dia. Você nunca deve fazer root em um sistema de produção sem uma boa razão.
2. Aprenda a lição importante. Quando você é root você tem que verificar duas vezes antes de pressionar enter. SUDO não é proteção se você simplesmente escrever sua senha para continuar, sem pensar. Coloração alerta, como mencionado por mkudlacek é uma ferramenta muito útil para ajudar a garantir que você não está no sistema errado.
3. Não mexa nas ferramentas incorporadas. É provável que ele quebre as atualizações e deixe as novas contratações insanas. Se você quiser alterar alguma coisa, use seu próprio arquivo de alias.

Answer 4

Eu não acho que mexer com as permissões em shutdown seja a maneira de lidar com a situação. Basicamente, você acabou de aprender uma lição. Queixo para cima.

Eu fiz o mesmo tipo de coisas - consegui longas cadeias de sessões de ssh, depois mexi com as rotas em uma das máquinas que eu estava passando, me cortando. Eu estraguei um pedido de rsync, levando a uma destruição sistemática de um sistema no outro lado do mundo. Eu executei rm -rf / path em um servidor de produção. (Naquela época eu aprendi como as restaurações funcionavam.)

Então, muito mais velho e esperançosamente um pouco mais sábio, agora tenho regras rígidas que eu imponho a mim mesmo.

• Todos os prompts de raiz terminam com #, não importando qual seja a outra informação neles.
• Sempre que estou em um # prompt, eu literalmente sento em minhas mãos antes de pressionar a tecla Enter.
• Se houver alguma dúvida sobre o que estou prestes a fazer ou onde realmente estou ou como cheguei lá, cancelo o processo e recomendo-o novamente a partir de uma condição inicial conhecida.
• Quando eu cometo um erro (e eu ainda os faço, embora eles estejam ficando menos frequentes e mais obscuros com o passar do tempo), imediatamente descubra o que eu fiz, quem eu impactou, e confesse meu pecados para eles. Então largue todo o resto e desfaça o damange o mais rápido e melhor que puder.

A natureza do meu trabalho requer que eu passe muito tempo em muitos prompts de raiz variados, mas graças aos meus erros no passado, eu mantenho uma consciência situacional muito melhor do que quando comecei.

    

Answer 5

Se você estiver usando o Ubuntu, tente o Molly-guard. Como discutido em esta questão semelhante .

    

Answer 6

Depende, realmente. Você poderia tentar apenas quebrar o comando, mas isso significa que, se você fizer atualizações ou upgrades que afetam esse executável, você pode esquecê-lo e tê-lo estragar uma atualização. Jogar com comandos de desligamento do sistema pode ser um PITA, especialmente se você tiver novos contratados ou um substituto que acabe não sabendo que você estava jogando com binários do sistema.

Pessoalmente, eu olharia para embrulhar o comando em um script que identifica o sistema pelo nome e faz com que você confirme o que você realmente quer fazer antes de executar o binário real, ou que você tenha que digitar uma certa seqüência de letras. para confirmar o desligamento antes de executar o binário. Isso deve dar uma pausa.

    

Answer 7

Você pode considerar configurar o prompt de comando para incluir o nome da máquina, pelo menos nos servidores. Isso pode ajudar a evitar que outros comandos sejam executados na máquina errada no futuro. É mais eficaz se os nomes das máquinas forem coloridos para que eles se destaquem e você pode até colorir o código para identificar as funções do servidor.

    

Answer 8

Uma maneira é não usar su e / ou fazer login diretamente em root . É melhor entrar diretamente na conta E ter uma senha diferente para root na máquina local e na chave ssh.

Claro que é, além de observar o prompt vermelho '#'.

    

Answer 9

Sim, remover o bit de execução no comando de desligamento é a maneira mais simples e segura de evitar desligamentos acidentais, especialmente se você tiver um ambiente de área de trabalho como o KDE na máquina e quiser evitar desligamentos acidentais ao fazer logout.

Quanto a novas pessoas ficarem confusas, acho que a primeira coisa que elas farão será ls -l /sbin/shutdown descobrir por que isso não funciona (especialmente se elas tiverem o bom hábito de completar os nomes dos executáveis). Obviamente, você deve informá-los sobre as alterações que você fez.

Para segurança extra, você pode adicionar uma linha a /etc/rc.local para remover o bit de execução do comando de desligamento para que você não esqueça de redefini-lo após a reinicialização.

    

Answer 10

você pode apenas remover / sbin / do caminho da raiz. Dessa forma, você precisa digitar o caminho completo para executá-lo e, geralmente, corrige os acidentes.