Estou criando uma API que aceita qualquer comando (no bash) e o executa na raiz. Eu quero garantir que este comando seja RO e não escreva nada. Alguma idéia de como fazer isso? Talvez possa temporariamente desativado com um temporizador ou tal?
Eu não acho que isso seja possível. Você pode garantir que qualquer coisa gravada em stdout ou stderr , por exemplo, seja redirecionada para /dev/null . No entanto, se o utilitário quiser gravar em um arquivo, não há como evitar ou até mesmo saber disso.
A prática de segurança padrão é nunca executar programas não confiáveis com privilégios de root.
Eu não acho que haja alguma maneira de, no caso geral, garantir que um programa aleatório não escreva nada em lugar algum. Você está olhando para algo parecido com a solução do problema da parada , com uma torção (stdout e stderr também são expostos como alças de arquivo) ).
Você pode, no entanto, criar uma pequena biblioteca que substitua o punhado relevante de chamadas de biblioteca padrão, como creat (2), open (2), write (2) e algumas outras, para não persistir em nada no disco. Isso provavelmente seria algo semelhante a libfaketime e deveria ser razoavelmente possível. Seria portátil para qualquer aplicação através do mecanismo de pré-carregamento da biblioteca LD_PRELOAD do carregador dinâmico.
No entanto, isso quase certamente não seria uma solução completa. Especialmente um processo que é executado como root poderia facilmente substituir qualquer um desses, se ele souber esperar e quiser fazer o mal. Por um lado, depende de tais chamadas passando pelas interfaces comuns como a biblioteca C, o que não é garantido; um processo poderia facilmente copiar o código da biblioteca C diretamente para seu próprio código. Ele poderia fazer chamadas diretas para as interfaces syscall do kernel. A biblioteca C não é uma coisa mágica; é o código do userspace como qualquer outro. E o binário pode ser vinculado estaticamente, caso em que o carregador dinâmico não será invocado. Provavelmente é possível contornar essas limitações e evitar gravações, mas ...
Fazer write-in (2) e amigos no-ops também é muito provável que quebrem as coisas de alguma outra forma, quando o processo espera que um arquivo que ele escreveu armazene os dados que foram escritos.
E se ele realmente não escrever nada, mas simplesmente ler alguns arquivos de configuração críticos para a segurança (/ etc / crypttab, / etc / shadow, /etc/bind/rndc.key, ... você obtém a ideia) e passa esses dados para outro lugar; pela rede, talvez, ou despeja-a para que ela se torne acessível através de um ataque de canal lateral?
Eu daria mais um passo do que o savanto . Prática de segurança padrão deve ser para não executar software não confiável, ponto final. E você definitivamente não deve executar software não confiável como root. Para qualquer coisa que rode como root, você pode colocar alguns obstáculos no caminho, mas você não pode garantir que não fará o que quiser. O SELinux pode ajudar, e provavelmente vai muito longe quando usado corretamente, mas é uma fera para configurar e vai É provável que qualquer violação de política leve a que a chamada em questão falhe com uma condição de erro e, possivelmente, um processo de aborto difícil, para que não seja nada gracioso.
O mais parecido com o que você parece querer fazer que eu possa pensar, que funcionará no caso geral, seria uma máquina virtual isolada com a capacidade de reverter as modificações feitas no disco (geralmente conhecido como recurso de reversão de instantâneo). Isso, no entanto, estará longe de ser perfeito, e virá com uma grande sobrecarga, já que você está, para todas as intenções e propósitos, executando uma segunda instância do sistema operacional, com tudo o que isso significa.
Esta não é uma resposta direta, mas eu procuraria sandbox ou máquina virtual .