Mais Qs semelhantes com mais respostas dignas de atenção:
NOTA: Algumas das respostas apontam para soluções específicas ainda não mencionadas aqui.
Na verdade, há muito poucas ferramentas de prisão com implementação diferente, mas muitos deles também não são seguros por design (como fakeroot, LD_PRELOADbaseados), ou não completo (como fakeroot-ng, ptracebaseados), ou exigiria raiz ( chrootou plashmencionado no fakechroot etiqueta de aviso ).
Estes são apenas exemplos; Pensei em listá-los todos lado a lado, com indicação desses dois recursos ("pode ser confiável?", "Requer a instalação do root?"), Talvez nas implementações de virtualização no nível do sistema operacional .
Em geral, as respostas abrangem toda a gama descrita de possibilidades e ainda mais:
máquinas virtuais / SO
extensão do kernel (como o SELinux)
- (mencionado nos comentários aqui),
chroot
Ajudantes baseados em Chroot (que, no entanto, devem ser raiz setUID, porque chrootrequer raiz; ou talvez chrootpossam funcionar em um espaço para nome isolado - veja abaixo):
[para contar um pouco mais sobre eles!]
Ferramentas conhecidas de isolamento baseadas em chroot:
- hasher com seus comandos
hsh-rune hsh-shell. (O Hasher foi projetado para criar software de maneira segura e repetível.)
- schroot mencionado em outra resposta
- ...
ptrace
Outra solução de isolamento de confiança (além de um seccompum com base ) seria o syscall-intercepção completa através de ptrace, como explicado na página de manual para fakeroot-ng:
Diferente das implementações anteriores, o fakeroot-ng usa uma tecnologia que deixa o processo rastreado sem escolha quanto ao uso ou não dos "serviços" do fakeroot-ng. Compilar um programa estaticamente, chamar diretamente o kernel e manipular o próprio espaço de endereço são todas técnicas que podem ser usadas trivialmente para ignorar o controle baseado em LD_PRELOAD sobre um processo e não se aplicam ao fakeroot-ng. Teoricamente, é possível moldar o fakeroot-ng de maneira a ter controle total sobre o processo rastreado.
Embora seja teoricamente possível, isso não foi feito. O Fakeroot-ng assume certas suposições "bem comportadas" sobre o processo que está sendo rastreado, e um processo que quebra essas suposições pode ser capaz de, se não escapar totalmente, pelo menos contornar um pouco do ambiente "falso" imposto a ele pelo fakeroot- ng. Como tal, você é fortemente advertido contra o uso do fakeroot-ng como uma ferramenta de segurança. Os relatórios de bugs que afirmam que um processo pode deliberadamente escapar (ao contrário de inadvertidamente) do controle do fake-root-ng serão fechados como "não são bugs" ou marcados como de baixa prioridade.
É possível que essa política seja repensada no futuro. Por enquanto, no entanto, você foi avisado.
Ainda assim, como você pode ler, ele fakeroot-ngpróprio não foi projetado para esse fim.
(BTW, eu me pergunto por que eles escolheram usar a seccompabordagem baseada em Chromium em vez de ptracebaseada em ...)
Das ferramentas não mencionadas acima, observei Geordi por mim mesmo, porque gostei do programa de controle escrito em Haskell.
Ferramentas conhecidas de isolamento baseadas em ptrace:
seccomp
Uma maneira conhecida de obter isolamento é por meio da abordagem de sandboxing seccomp usada no Google Chromium . Mas essa abordagem supõe que você escreva um auxiliar que processe alguns (os permitidos) do acesso a arquivos "interceptados" e outros syscalls; e também, é claro, faça um esforço para "interceptar" os syscalls e redirecioná-los para o ajudante (talvez até signifique substituir os syscalls interceptados no código do processo controlado; portanto, não soa para ser bem simples; se você estiver interessado, é melhor ler os detalhes em vez de apenas a minha resposta).
Mais informações relacionadas (da Wikipedia):
(O último item parece interessante se alguém estiver procurando uma seccompsolução baseada em geral fora do Chromium. Há também uma postagem no blog que vale a pena ser lida pelo autor de "seccomp-nurse": SECCOMP como uma solução Sandboxing?. )
A ilustração dessa abordagem do projeto "seccomp-nurse" :
Um segundo componente "flexível" possível no futuro do Linux?
Costumava aparecer em 2009 também sugestões para corrigir o kernel do Linux para que haja mais flexibilidade no seccompmodo - para que "muitas das acrobacias de que precisamos atualmente possam ser evitadas". ("Acrobatics" refere-se às complicações de escrever um auxiliar que precisa executar muitos syscalls possivelmente inocentes em nome do processo preso e de substituir os syscalls possivelmente inocentes no processo preso.) Um artigo do LWN escreveu a este ponto:
Uma sugestão que surgiu foi adicionar um novo "modo" ao seccomp. A API foi projetada com a ideia de que aplicativos diferentes podem ter requisitos de segurança diferentes; inclui um valor "mode" que especifica as restrições que devem ser implementadas. Somente o modo original já foi implementado, mas outros certamente podem ser adicionados. Criar um novo modo que permitisse ao processo inicial especificar quais chamadas do sistema seriam permitidas tornaria o recurso mais útil para situações como a sandbox do Chrome.
Adam Langley (também do Google) postou um patch que faz exatamente isso. A nova implementação do "modo 2" aceita uma máscara de bits descrevendo quais chamadas do sistema são acessíveis. Se um deles for prctl (), o código em área restrita poderá restringir ainda mais suas próprias chamadas de sistema (mas não poderá restaurar o acesso às chamadas de sistema que foram negadas). Ao todo, parece uma solução razoável que poderia facilitar a vida dos desenvolvedores de sandbox.
Dito isto, esse código nunca pode ser mesclado porque a discussão passou para outras possibilidades.
Esse "seccomp flexível" aproximaria as possibilidades do Linux de fornecer o recurso desejado no sistema operacional, sem a necessidade de escrever auxiliares tão complicados.
(Uma postagem de blog com basicamente o mesmo conteúdo que esta resposta: http://geofft.mit.edu/blog/sipb/33 .)
namespaces ( unshare)
Isolar através de namespaces ( unsharesoluções baseadas em ) - não mencionados aqui - por exemplo, pontos de montagem não compartilhados (combinados com o FUSE?) Talvez possam ser parte de uma solução funcional para você que deseja restringir acessos ao sistema de arquivos de seus processos não confiáveis.
Mais sobre espaços para nome, agora, quando sua implementação foi concluída (essa técnica de isolamento também é conhecida sob o nme "Linux Containers", ou "LXC" , não é? ..):
"Um dos objetivos gerais dos namespaces é oferecer suporte à implementação de contêineres, uma ferramenta para virtualização leve (além de outros fins)" .
É até possível criar um novo espaço para nome de usuário, para que "um processo possa ter um ID de usuário não privilegiado normal fora de um espaço para nome de usuário e, ao mesmo tempo, tenha um ID de usuário 0 dentro do espaço para nome. Isso significa que o processo tem privilégios de root completos para operações dentro do espaço para nome do usuário, mas não tem privilégios para operações fora do espaço para nome ".
Para comandos de trabalho reais para fazer isso, consulte as respostas em:
e programação / compilação especiais do espaço do usuário
Mas bem, é claro, as garantias de "prisão" desejadas são implementáveis através da programação no espaço do usuário ( sem suporte adicional para esse recurso do sistema operacional ; talvez seja por isso que esse recurso não tenha sido incluído em primeiro lugar no design dos sistemas operacionais) ); com mais ou menos complicações.
O mencionado ptrace- ou seccompsandboxing baseada pode ser visto como algumas variantes da implementação das garantias por escrito uma sandbox-auxiliar que iria controlar seus outros processos, que seriam tratados como "caixas pretas", arbitrária programas Unix.
Outra abordagem poderia ser o uso de técnicas de programação que se importam com os efeitos que devem ser proibidos. (Deve ser você quem escreve os programas então; eles não são mais caixas pretas.) Para mencionar um, usar uma linguagem de programação pura (que forçaria você a programar sem efeitos colaterais) como Haskell simplesmente causará todos os efeitos do programa explícito, para que o programador possa facilmente garantir que não haverá efeitos não permitidos.
Eu acho que existem facilidades de sandbox disponíveis para aqueles que programam em alguma outra linguagem, por exemplo, Java.
Algumas páginas que acumulam informações sobre esse tópico também foram apontadas nas respostas: