Como proteger opções de linha de comando potencialmente destrutivas?

Question

Estou curioso se alguém puder me ajudar com a melhor maneira de proteger as opções de linha de comando potencialmente destrutivas para um aplicativo de linha de comando do Linux?

Para dar um cenário muito hipotético: imagine um programa de linha de comando que defina a configuração térmica máxima para um processador antes do desligamento de emergência. Vamos ainda fingir que existem duas opções principais, uma das quais é --max-temperature (em Celsius), que pode ser definida para qualquer número inteiro entre 30 & 50. Há também um sinalizador de substituição --melt que desabilitaria o processador de desligar por meio de software, independentemente de quão quente o processador ficou, até que o sistema falhou elétrica / mecanicamente.

Certamente tal opção como --melt é perigosa e pode causar destruição física na pior das hipóteses. Mas, novamente, vamos fingir que esse tipo de funcionalidade é uma exigência (ainda que estranha). O aplicativo deve ser executado como root, mas se houver o desejo de ajudar a garantir que a opção --melt não seja acidentalmente acionada por usuários confusos ou que não tenham experiência, como você faria isso?

Certamente um anti-padrão muito comum (IMO) é ocultar a opção, de modo que --help ou a página do manual não revelem sua existência, mas isso é segurança através da obscuridade e poderia ter a consequência não intencional de um usuário desencadeando-o, mas não sendo capaz de descobrir o que isso significa.

Outra possibilidade é alterar o sinalizador para um argumento de linha de comando que exija que o usuário passe --melt OVERRIDE, ou algum outro token como um significante que REALMENTE signifique fazer isso.

Existem outros mecanismos para atingir o mesmo objetivo?

    

Answer 1

Suponho que você esteja vendo isso a partir do POV do programador utilitário. Isso é amplo o suficiente para que não haja (e não possa ser) uma única resposta certa, mas algumas coisas vêm à mente.

Acho que a maioria dos utilitários tem apenas um único sinalizador de "força" ( -f ), que substitui a maioria das verificações de segurança. Por outro lado, por ex. dpkg tem uma opção --force-things mais detalhada, em que coisas podem ser várias palavras-chave diferentes.

E apt-get faz você escrever uma frase completa para verificar, em alguns casos, como remover pacotes "essenciais". Ver abaixo. (Acho que não é apenas uma opção de linha de comando aqui, pois pacotes essenciais são, por exemplo, aqueles que são necessários para instalar pacotes, então desfazer uma ação equivocada pode ser muito difícil. Além disso, toda a operação pode não ser conhecido de antemão, antes de apt ter tido a chance de calcular as dependências do pacote.)

Então, acho que cdrecord costumava fazer o usuário esperar alguns segundos antes de iniciar o trabalho, para que você tivesse a chance de verificar se as configurações estavam certas enquanto os números estavam acabando.

Veja o que você obtém se tentar apt-get remove bash :

WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  bash
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 2,870 kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] ^C

Qual escolher é com você como o autor do programa - você terá que basear a decisão no nível de perigo da ação e no seu próprio nível de paranoia. (Seja baseado no cuidado com seus usuários ou no medo de ser culpado pela bagunça.)

Algo que tem o potencial de fazer com que o processador literalmente (parar e) pegar fogo provavelmente fica na extremidade mais alta do eixo "perigo" e provavelmente garante algo como o tipo "Sim, faça o que eu digo" .

Dito isso, uma coisa é perceber que muitas das interfaces reais no nível do kernel não são protegidas por nenhum meio. Em vez disso, há arquivos em /sys que podem alterar as coisas apenas por serem abertos e gravados, sem perguntas, além das permissões de acesso a arquivos. (ou seja, você precisa ser root).

Isso também vale para o conteúdo do disco rígido (como deveríamos saber) e, em um caso, dois anos atrás, para as variáveis de configuração do firmware da placa-mãe. Parece que era possível "tijolo" computadores com um rm -rf mal posicionado.

Não, realmente. Veja artigo do lwn.net e o rastreador de problemas do systemd .

Assim, quaisquer proteções que você implementasse, você protegeria apenas as ações feitas usando essa ferramenta específica.