Execução de programa possivelmente prejudicial no Linux

Estou escrevendo um programa que testará programas escritos por alunos. Receio não poder confiar neles e preciso ter certeza de que não acabará mal para o computador que está executando.

Eu estava pensando em criar um usuário de teste de falha com acesso limitado aos recursos do sistema e executar programas como esse usuário, mas pelo que encontrei na rede até agora, criar um sistema virtual seria a opção mais segura ...

Alguém pode me ajudar com a escolha da abordagem correta? A segurança é uma grande preocupação para mim. Por outro lado, não quero uma solução que exagere e perca muito tempo tentando aprender algo que realmente não preciso.

• A máquina virtual pode oferecer a maior segurança sem reinicialização, mas o menor desempenho.

• Outra opção, para uma segurança ainda maior do que uma máquina virtual: inicialize um CD / DVD / pendrive "ao vivo" sem acesso ao disco rígido (desative temporariamente o HD no BIOS; se você não puder, pelo menos não monte a unidade / desmonte-o, se montado automaticamente - mas isso é muito menos seguro)

• Um contêiner de docker é uma alternativa um pouco menos segura a uma máquina virtual completa. Provavelmente, a diferença crucial (em termos de segurança) entre esses dois é que os sistemas em execução no docker realmente usam o kernel do seu sistema host.

• Existem programas como o isolate que criarão um ambiente especial e seguro - geralmente chamado de sandbox -, geralmente baseados em chroot, com supervisão adicional - e encontre um que se adapte a você.

• Um chroot simples será menos seguro (especialmente em relação à execução de programas), embora talvez um pouco mais rápido, mas ... Você precisará criar / copiar uma árvore raiz inteira separada e usar montagens de ligação para /devetc. (consulte a Nota 1 abaixo!). Portanto, em geral, essa abordagem não pode ser recomendada, especialmente se você puder usar um ambiente mais seguro e geralmente mais fácil de configurar sandbox.

Nota 0: Para o aspecto de um "usuário especial", como anobodyconta: isso dá quase nenhuma segurança, muito menos que um simpleschroot. Umnobodyusuário ainda pode acessar arquivos e programas que possuempermissões de leitura e execução definidas para outros . Você pode testá-lo comsu -s /bin/sh -c 'some command' nobody. E se você tiver qualquer arquivo de configuração / histórico / cache acessível a qualquer pessoa (por um erro ou pequena falha de segurança), um programa em execução comnobodyas permissões poderá acessá-lo, grep por dados confidenciais (como "pass =" etc.) e em de várias maneiras, enviá-lo pela rede ou qualquer outra coisa.

Nota 1: Como Gilles apontou em um comentário abaixo , um ambiente chroot simples dará muito pouca segurança contra explorações que visam escalar privilégios. Um chroot único faz sentido em termos de segurança, apenas se o ambiente for mínimo, consistindo apenas em programas confirmados por segurança(mas ainda existe o risco de explorar possíveis vulnerabilidades no nível do kernel) e todos os programas não confiáveis ​​em execução no chroot estão em execução. como um usuário que não executa nenhum processo fora do chroot. O que o chroot impede (com as restrições mencionadas aqui) é a penetração direta do sistema sem escalação de privilégios. No entanto, como Gilles observou em outro comentário, mesmo esse nível de segurança pode ser contornado, permitindo que um programa saia do chroot.

Use uma máquina virtual. Qualquer coisa menos não fornece muita segurança.

Alguns anos atrás, eu poderia ter sugerido um usuário dedicado com chroot ou algo assim. Mas o hardware se tornou mais poderoso e o software da máquina virtual se tornou mais fácil de usar. Além disso, ataques de prateleira tornaram-se mais sofisticados. Não há mais motivo para não percorrer todo o caminho até aqui.

Eu recomendaria executar o VirtualBox. Você pode configurar a máquina virtual em alguns minutos e instalar uma distribuição Linux nela. A única configuração não padrão que eu recomendo é a configuração de rede: crie uma interface "NAT" (para se comunicar com o mundo) e uma interface "somente host" (para que você possa copiar facilmente os arquivos de e para o host e o ssh para a VM). Desabilite a interface NAT enquanto você executa os programas de seus alunos¹; habilite-o somente quando estiver instalando ou atualizando pacotes de software.

Dentro da máquina virtual, crie um usuário por aluno.

¹ _{Você pode restringir a interface NAT a uma lista de permissões de usuários, mas isso é mais avançado do que você precisa em uma configuração simples e direta.}

Aqui está uma explicação muito detalhada sobre por que o uso do Chroot ainda é uma opção muito viável e por que o sistema operacional completo ou a virtualização completa de hardware é especialmente exagerada em cenários específicos.

nada mais é do que um mito de que Chroot não é um recurso de segurança. existem ferramentas que criarão o sistema de arquivos chroot automaticamente para você e o Chroot é incorporado a muitos aplicativos populares como um recurso de segurança proposital.

contrariamente à crença popular, nem toda situação requer virtualização completa do sistema operacional ou simulação completa de hardware. isso pode realmente significar ter mais superfície de ataque para tentar cobrir. por sua vez, significando um sistema menos seguro . (supostamente para administradores de sistema com menos conhecimento)

as regras são bastante simples: não coloque nada dentro do chroot que não seja necessário. não execute um daemon como root. não execute um daemon como qualquer usuário executando um daemon fora do chroot.

remova todos os aplicativos não seguros, binários setuid, links / links simbólicos sem proprietário pendentes. remonte pastas desnecessárias usando nosuid, noexec e nodev. construa a versão estável mais recente do daemon em execução a partir da fonte. e, acima de tudo, proteja o sistema básico!

Vou acrescentar isso, bem depois que a pergunta for oficialmente respondida: MÁGICA: Envelhecimento Malicioso em Circuitos / Núcleos , que infelizmente está trancado atrás do paywall da ACM. O resultado final do trabalho é que a largura muito pequena traçada nos circuitos em uso hoje envelhece durante o uso e acaba quebrando. Ao encontrar as instruções corretas e repeti-las repetidamente, um invasor pode envelhecer rapidamente os ICs.

Nenhuma VM, sandbox, container ou chroot jail impediria esse tipo de destruição maliciosa de hardware. Os autores do artigo descobriram essas seqüências de instruções e o hardware envelhecido experimentalmente até o fracasso, mas não revelaram as instruções, portanto pode não ser uma ameaça real por um tempo.

Nos unixes derivados do BSD (incluindo o Mac OS X), existe um recurso chamado sandbox. A página de manual diz

DESCRIÇÃO
A sandbox recurso permite que os aplicativos restrinjam voluntariamente seu acesso aos recursos do sistema operacional. Esse mecanismo de segurança destina-se a limitar possíveis danos no caso de uma vulnerabilidade ser explorada. Não substitui outros controles de acesso do sistema operacional.

Isso é separado da chrootinstalação que também está disponível.