Introdução
Ferramentas de segurança e arquivos de evidências são executados sob identidades de usuário. Entender essas identidades ajuda você a escolher as permissões necessárias para uma tarefa sem tornar todos os arquivos acessíveis a todas as contas.
Você criará uma conta de prática dentro do Kali, atribuirá a ela um diretório de caso privado e testará o acesso permitido e o negado. Este laboratório aborda usuários locais e permissões de arquivos; processos e logs têm seu próprio laboratório mais adiante.
Identifique usuários e crie uma conta de prática
Nesta etapa, você distinguirá a identidade de usuário comum da autoridade de administrador e criará uma conta local separada dentro do Kali.
Entre no shell Kali preparado e selecione o espaço de trabalho compartilhado:
kali
cd /home/labex/project
id mostra seu ID numérico de usuário (UID), ID de grupo primário (GID) e participação em grupos:
id
O nome de usuário é kali; os IDs numéricos podem variar entre ambientes. O UID 0 identifica root, o administrador. Sua conta comum tem um UID diferente de zero.
sudo executa um comando autorizado com privilégios mais altos. Este contêiner de treinamento permite que o aprendiz do Kali o use sem senha. Essa permissão é local ao contêiner; não é motivo para executar todos os comandos como root. Peça a root que se identifique em um único comando:
sudo whoami
A saída é root. A elevação termina quando esse comando é concluído:
whoami
A saída continua sendo kali.
Uma conta local tem nome, UID, grupo, diretório pessoal e shell de login. useradd cria uma conta e exige autoridade de administrador. --create-home cria seu diretório pessoal, --user-group cria um grupo primário com o mesmo nome e --shell /bin/bash escolhe Bash como shell:
sudo useradd --create-home --user-group --shell /bin/bash practice-analyst
Faça isso uma vez em um laboratório novo; uma mensagem de conta existente significa que a conta já está presente. Não são necessários senha nem acesso SSH para este exercício. Inspecione a nova identidade passando seu nome para id:
id practice-analyst
A saída nomeia practice-analyst como usuário e grupo primário. Seu UID deve ser diferente dos de kali e root.
Atribua propriedade e permissões privadas
Nesta etapa, você criará um diretório de caso, transferirá sua propriedade e limitará o acesso à conta atribuída.
Retorne ao espaço de trabalho compartilhado:
cd /home/labex/project
Crie um diretório como seu usuário comum:
mkdir case-files
ls -ld descreve o próprio diretório: -l solicita saída detalhada, enquanto -d impede que seu conteúdo seja listado em seu lugar:
ls -ld case-files
A saída inclui caracteres de permissão, um proprietário e um grupo. Inicialmente o proprietário é kali. O primeiro caractere, d, significa diretório. As nove posições seguintes formam três grupos de bits de leitura (r), escrita (w) e execução (x) para proprietário, grupo e outros. Em um diretório, leitura lista nomes, escrita altera entradas e execução permite atravessar o diretório para acessar suas entradas.
chown altera a propriedade. A forma user:group atribui tanto o proprietário quanto o grupo; é necessária autoridade de administrador para transferir a propriedade a outra conta:
sudo chown practice-analyst:practice-analyst case-files
chmod altera permissões. Na forma numérica, leitura vale 4, escrita vale 2 e execução vale 1. A soma 7 concede as três; 0 não concede nenhuma. O modo 700 dá acesso completo ao proprietário e não concede acesso ao diretório para grupo ou outros:
sudo chmod 700 case-files
ls -ld case-files
O início deve mostrar drwx------, e proprietário e grupo devem ser practice-analyst. Datas e tamanhos numéricos podem variar. A propriedade escolhe qual conta recebe as permissões de proprietário; o modo define o acesso concedido a cada categoria.
Teste o acesso como a conta pretendida
Nesta etapa, você verificará o acesso usando identidades de usuário reais em vez de depender apenas de uma listagem de permissões.
sudo -u NAME executa um comando como o usuário nomeado em vez de root. Use o proprietário do caso para criar um arquivo em seu diretório privado:
sudo -u practice-analyst touch /home/labex/project/case-files/checked.txt
Não se espera nenhuma saída. Inspecione o resultado como a mesma conta:
sudo -u practice-analyst ls -l /home/labex/project/case-files
O arquivo vazio checked.txt deve pertencer a practice-analyst. Sua criação prova que essa conta pode atravessar e gravar no diretório.
A conta comum do Kali não deve ter esse acesso. Espera-se que o próximo comando falhe com uma mensagem de permissão negada, demonstrando a restrição. Continue após o erro:
ls /home/labex/project/case-files
Root ainda pode inspecionar o diretório por meio de um comando explicitamente autorizado:
sudo ls /home/labex/project/case-files
Você deve ver checked.txt. Permissões privadas restringem contas comuns; root mantém autoridade administrativa. Continue usando kali para o trabalho normal e eleve somente a operação específica que exige isso. Nenhum desses comandos altera a conta do aprendiz no host nem a forma como o LabEx se conecta à VM.
Resumo
Você inspecionou identidades de usuário, usou sudo para ações administrativas específicas, criou uma conta e atribuiu propriedade e permissões de diretório. Confirmou que a conta pretendida podia trabalhar enquanto o acesso de outra conta comum era negado.
