Execução de programa possivelmente nocivo no Linux

Question

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

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

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

    

Answer 1

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

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

• Um contêiner docker é uma alternativa um pouco menos segura para 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 de seu sistema host.

• Existem programas como isolar que criará um ambiente especial e seguro - isso geralmente é chamado de sandbox - esses são tipicamente baseados em chroot, com supervisão adicional - encontre um que se encaixe em você.

• Um chroot simples será menos seguro (especialmente em relação à execução de programas), embora talvez um pouco mais rápido, mas ... Você precisa construir / copiar uma árvore raiz inteira e usar montagens de bind para /dev etc. (veja Nota 1 abaixo!). Portanto, em geral, essa abordagem não pode ser recomendada, especialmente se você puder usar um ambiente mais seguro e muitas vezes mais fácil de configurar, sandbox .

Observação 0: Para o aspecto de um "usuário especial", como a conta nobody : Isso dá a quase nenhuma segurança, muito menos do que um simples chroot . Um usuário nobody ainda pode acessar arquivos e programas que tenham as permissões ler e executar definidas para outras . Você pode testá-lo com su -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 falha de segurança menor), um programa rodando com permissões nobody pode acessá-lo, grep para dados confidenciais (como "pass=" etc. ) e de muitas maneiras, enviá-lo pela rede ou qualquer outra coisa.

Nota 1: Como Gilles apontou em um comentário abaixo , um simples ambiente chroot dará muito pouca segurança contra exploits visando escalação de privilégios. Um único chroot faz sentido em termos de segurança, somente se o ambiente for mínimo, consistindo em programas confirmados por segurança somente (mas ainda existe o risco de explorar potenciais níveis de kernel) vulnerabilidades), e todos os programas não confiáveis em execução no chroot estão sendo executados 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 escalonamento de privilégios. No entanto, como Gilles observou em outro comentário , até mesmo esse nível de segurança pode ser contornado, permitindo que um programa saia do chroot.

    

Answer 2

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

Há alguns anos, eu poderia ter sugerido um usuário dedicado chrooted ou algo assim. Mas o hardware se tornou mais poderoso e o software de máquinas virtuais se tornou mais fácil de usar. Além disso, ataques de prateleira se tornaram mais sofisticados. Não há mais razão para não seguir todo o caminho até aqui.

Eu recomendaria rodar o VirtualBox. Você pode configurar a máquina virtual em alguns minutos e depois instalar uma distribuição do 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 arquivos de e para o host e ssh para a VM). Desabilite a interface NAT enquanto você executa os programas dos seus alunos¹; ative-o apenas 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 o necessário em uma configuração simples e direta.}

    

Answer 3

aqui é uma explicação muito minuciosa sobre por que usar o Chroot ainda é uma opção muito viável, e por que o sistema operacional completo ou a virtualização de hardware completa é especialmente exagerada em cenários específicos.

não é nada mais do que um mito que o Chroot não é um recurso de segurança. existem ferramentas que construirão o sistema de arquivos chroot automaticamente para você, e o Chroot é incorporado em muitos aplicativos tradicionais como um recurso de segurança intencional.

contrariamente à crença popular, nem toda situação requer virtualização completa do sistema operacional, ou simulação completa de hardware. isso pode 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 bem 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 que esteja executando um daemon fora do chroot.

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

    

Answer 4

Em unixes derivados do BSD (incluindo o Mac OS X) existe um recurso chamado sandbox . A manpage diz

DESCRIPTION
The sandbox facility allows applications to voluntarily restrict their access to operating system resources. This safety mechanism is intended to limit potential damage in the event that a vulnerability is exploited. It is not a replacement for other operating system access controls.

Isso é separado do recurso chroot , que também está disponível.

    

Answer 5

Vou adicionar isso, bem depois que a pergunta é oficialmente respondida: MÁGICA: Envelhecimento Malicioso em Circuitos / Núcleos , que infelizmente estão bloqueados atrás do paywall da ACM. O resultado final do artigo é que os traços de largura muito pequenos nos circuitos em uso hoje envelhecem durante o uso e acabam quebrando. Ao encontrar a (s) instrução (ões) correta (s) e repeti-las repetidas vezes, o invasor pode envelhecer os ICs rapidamente.

Nenhuma das VMs ou sandbox ou container ou chroot jail evitaria esse tipo de destruição maliciosa de hardware. Os autores do artigo encontraram essas sequências de instruções e, com o tempo, danificaram hardware experimentalmente, mas não deram instruções, por isso pode não ser uma ameaça real durante algum tempo.