Criando um ambiente seguro pra aprender a usar o terminal - 1/6

Introdução

Aprender algo novo é sempre interessante no entanto, por vezes aprender algo novo pode significar colocar algo importante (como o seu sistema) em risco, felizmente quando se trata de tecnologia quase sempre existe uma forma de se criar uma “caixa de areia” segura onde o máximo que pode acontecer é você estragar o seu “castelo de areia”, se algo der ruim, é só começar de novo, Quando se trata de Linux você tem uma solução nativa chamada chroot cujo nome significa:

ch   # CHange, ou seja mudar
root # ROOT, ou seja o diretório raiz

Resumidamente ele muda o diretório / para outro diretório que contenha um ambiente Linux com a mesma arquitetura que o original.

O ambiente protege contra ações descuidadas e não contra malwares

Requisitos:

  • debootstrap

Esse passo deve ser executado como usuário administrador

Para Debian e distros que usam o APT:

apt install debootstrap

Para CentOS 7:

wget "http://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-7-12.noarch.rpm"

rpm -Uvh "epel-release-"*".noarch.rpm"

yum install debootstrap.noarch

Para OpenSuse, Suse e derivados o “one click install” está disponível

Como fazer:

São poucos passos (2 pra ser exato) pra ter um ambiente chroot completo:

  1. Crie uma pasta onde vai ser criado o ambiente chroot:

Esse passo não deve ser executado como root, porque assim você poderá injetar arquivos e pastas sem usar ro usurário root.

mkdir -p meu-ambiente-de-testes
  1. Instale o ambiente chroot:

Esse passo deve ser executado como usuário administrador

debootstrap meu-ambiente-de-testes stable "http://ftp.br.debian.org/debian/"

Como usar:

  1. Entre na pasta criada anteriormente:
cd meu-ambiente-de-testes
  1. Inicie seu chroot:

Esse passo deve ser executado como usuário administrador

chroot .

Conclusão

Como se percebe criar um ambiente seguro de aprendizagem é relativamente simples, mas isso não é tudo, no próximo artigo nós vamos ver como usar aplicações gráficas dentro do ambiente “enjaulado”

5 curtidas

Não é mais interessante fazer tudo isso dentro de um container no Docker, ou até mesmo no toolbox(podman)?

2 curtidas

O toolbox depende de várias libs que não estão presentes nas distros “oldest supported” o que excluiria esses usuários e o Docker não é uma ferramenta destinada pra esse fim, tanto é que o docker foi projetado para usar um diretório fixo que o usuário não tem acesso por padrão, e ambas criam um overhead de uso de disco que o debootstrap não cria, e por fim o debootstrap permite criar o ambiente “aonde for necessário”

Esses são os motivos da escolha pelo debootstrap

1 curtida