Sandbox uma conta e impedi-lo de quaisquer modificações do sistema

Question

Estou tentando proteger uma conta de usuário até o ponto em que ela não possa editar ou visualizar nenhum arquivo além de uma determinada pasta, ou seja, /home/user/test . Essa conta estará compilando e executando um programa C ++ que pode sujeitar o sistema a qualquer comando e não poderá modificar ou editar o sistema de qualquer forma.

Isso significa desabilitar su e sudo , removendo permissões de gravação (e algumas de leitura) de todo o sistema para esse usuário e mantendo o programa bloqueado (preso) dentro de sua própria pasta. Há mais alguma coisa que eu esteja sentindo falta?

Agora, para a implementação.

Acredito que posso encontrar a localização de su e sudo digitando whereis su e whereis sudo , respectivamente. Por sudo , por exemplo, posso descobrir que os binários estão em:

/usr/bin/sudo /usr/lib/sudo /usr/bin/X11/sudo /usr/share/man/man8/sudo.8.gz

Se eu alterar as permissões desses binários para impedir a execução para esse usuário, isso evitará sudo ing por outros meios, como em outras linguagens de programação?

Para "prender" o programa em uma determinada pasta, parece que chroot é ineficaz, especialmente se o programa precisar de acesso a outros recursos que estão fora da pasta de área restrita. Qual é a melhor maneira de fazer isso, então?

    

Answer 1

É melhor encontrar o que você precisa incluir no seu chroot do que descobrir que você esqueceu algum programa que poderia ser usado como porta dos fundos. Você acabou de fazer links para o material que você precisa sob a estrutura chrooted. E qualquer coisa que você tenha esquecido de incluir você descobrirá na primeira execução de compilação.

Sempre que tive esse requisito, usei máquinas virtuais para essa compilação de tipo desde 2000. Não se preocupa com o que essa conta faz, nem com outras atividades no sistema (instalação de software, etc.) que poderiam interromper o processo de compilação. Fácil de fazer instantâneos antes de atualizar as coisas, etc. Para isso, a sobrecarga da VM em termos de degradação de velocidade é um preço muito pequeno a pagar.