Como "encarcerar" um processo sem ser root?


26

Se eu fosse root, poderia simplesmente criar um usuário / grupo fictício, definir permissões de arquivo de acordo e executar o processo como esse usuário. No entanto, não sou, então existe alguma maneira de conseguir isso sem ser raiz?


11
@alex: Eu tenho um script executando várias simulações (em diretórios diferentes) e quero ter certeza de que, por pior que seja a programação, eles podem acessar apenas arquivos em seu próprio diretório e não modificar acidentalmente, por exemplo, a saída das outras simulações
Tobias Kienzler

2
@ Tobias: Entendi o seu ponto. chrootcaberia naturalmente lá, mas, novamente, você não é raiz.
25411 alex

11
Eu acho que selinux, apparmor e grsecurity podem ser capazes de fazer isso, mas não tenho certeza. mas se eles não estiverem disponíveis ou configurados pelo administrador do sistema, você estará satisfeito com isso.
Xenoterracide

4
Essa pergunta tem sido algo para me perguntar há anos. Parece ser um desejo tão natural: sem ser root, poder executar processos com algumas das permissões de usuário descartadas, ou seja, poder limitar um processo a uma "prisão" de configuração do usuário, o que daria ao processo menos direitos que seu usuário. É uma pena que os Unices usuais não tenham oferecido isso de maneira padrão!
imz - Ivan Zakharyaschev 11/03/11

2
Tente pedir ao administrador do sistema para fazer de você uma segunda conta de usuário.
22811 LawrenceC em

Respostas:


23

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" :

                      insira a descrição da imagem aqui

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:


Rootless GoboLinux pode ser uma opção bem ...
Tobias KIENZLER

@tobias mas não Rootless Gobolinux dar uma garantia de que um programa escrito por um usuário não terá acesso ao ambiente externo ..?
IMZ - Ivan Zakharyaschev

11
Na verdade, não - eu estava de alguma forma com a idéia errada de que isso também permitiria que alguém se tornasse um usuário raiz "local", o que poderia simplesmente criar usuários virtuais para esse processo - embora possa ser possível usá-lo chroot, mas isso provavelmente ainda exigiria privilégios de root reais ...
Tobias Kienzler 30/10

8

Essa é uma limitação fundamental do modelo de permissão unix: somente o root pode delegar.

Você não precisa ser root para executar uma máquina virtual (não é verdade em todas as tecnologias de VM), mas esta é uma solução pesada.

O modo de usuário Linux é uma solução de virtualização Linux-Linux relativamente leve. Não é tão fácil de configurar; você precisa preencher uma partição raiz (em um diretório) com pelo menos o (alguns arquivos no mínimo necessário para inicialização /etc, /sbin/initum programa de login e suas dependências, um shell e utilitários).


1

Eu acho que você pode ter alguma sorte LD_PRELOADem interceptar o acesso a determinados arquivos, mas isso pode ser realmente complicado.


O sandboxing seccomp do Google Chromium faz uma coisa mais confiável: interceptação de syscall, efetivamente. - unix.stackexchange.com/questions/6433/...
IMZ - Ivan Zakharyaschev

A diferença entre apenas tentar interceptar algo e sanboxing (como no caso do Chromium) é a garantia do isolamento.
imz - Ivan Zakharyaschev

11
A interceptação por meio LD_PRELOADnão pode ser confiável (pode ser contornada), mas a interceptação por meio deptrace lata.
imz - Ivan Zakharyaschev

11
Um exemplo simples é apresentado aqui < joey.kitenet.net/blog/entry/fakechroot_warning_label > que mostra que as LD_PRELOADsoluções baseadas em não podem ser confiáveis ​​como medida de segurança.
imz - Ivan Zakharyaschev 12/03/11

0

Da lista completa, eu apenas acrescentaria:

  • fakeroot (do mantenedor de pacotes debian): visa criar pacotes com ferramentas "amigáveis". Este não é um isolamento completo, mas ajuda a criar pacotes com diferentes usuários e dispositivos falsos e outros pseudo-arquivos especiais.

  • fakechroot (que usa fakeroot). Este programa tem muitos erros. Por exemplo, "/ etc / hosts" é codificado na glibc: você não pode alterá-lo através desta ferramenta.

  • qemu: você precisa compilar um kernel do linux, mas o resultado é muito rápido, e esta é uma máquina "falsa" (ou seja, virtual) com privilégios de root reais. Você pode criar e montar qualquer imagem de inicialização.


0

O Firejail é uma ótima ferramenta para prender qualquer processo, com ou sem acesso root, com muitas opções e muito flexível:


2
Um pouco mais de detalhes sobre como usar o firejail seria bem-vindo. Depois que o link se esgotar, o conteúdo das informações das respostas será reduzido apenas para o nome dos utilitários. (inclua aqui se houver pacotes disponíveis em distribuições, como usá-lo etc).
Anthon
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.