Introducción
Las herramientas de seguridad y los archivos de evidencia funcionan bajo identidades de usuario. Comprender esas identidades te ayuda a elegir los permisos necesarios para una tarea sin hacer que todos los archivos sean accesibles para todas las cuentas.
Crearás una cuenta de práctica dentro de Kali, le asignarás un directorio de caso privado y probarás el acceso permitido y denegado. Esta práctica cubre usuarios locales y permisos de archivos; los procesos y registros tienen su propia práctica posterior.
Identifica usuarios y crea una cuenta de práctica
En este paso distinguirás la identidad de usuario normal de la autoridad de administrador y crearás una cuenta local independiente dentro de Kali.
Entra en el shell Kali preparado y selecciona el espacio de trabajo compartido:
kali
cd /home/labex/project
id muestra tu identificador numérico de usuario (UID), el identificador de grupo principal (GID) y tus grupos:
id
El nombre de usuario es kali; los identificadores numéricos pueden variar entre entornos. El UID 0 identifica a root, el administrador. Tu cuenta normal tiene un UID distinto de cero.
sudo ejecuta un comando autorizado con privilegios superiores. Este contenedor de entrenamiento permite al estudiante de Kali utilizarlo sin contraseña. Este permiso es local al contenedor; no es un motivo para ejecutar todos los comandos como root. Pide a root que se identifique para un solo comando:
sudo whoami
La salida es root. La elevación termina cuando finaliza ese comando:
whoami
La salida sigue siendo kali.
Una cuenta local tiene nombre, UID, grupo, directorio personal y shell de inicio de sesión. useradd crea una cuenta y requiere autoridad de administrador. --create-home crea su directorio personal, --user-group crea un grupo principal coincidente y --shell /bin/bash elige Bash como shell:
sudo useradd --create-home --user-group --shell /bin/bash practice-analyst
Hazlo una vez en una práctica nueva; un mensaje de cuenta existente significa que ya está presente. Este ejercicio no necesita contraseña ni acceso SSH. Inspecciona la nueva identidad pasando su nombre a id:
id practice-analyst
La salida nombra practice-analyst tanto como usuario como grupo principal. Su UID debe diferir del de kali y root.
Asigna propiedad y permisos privados
En este paso crearás un directorio de caso, transferirás su propiedad y limitarás el acceso a la cuenta asignada.
Vuelve al espacio de trabajo compartido:
cd /home/labex/project
Crea un directorio como tu usuario normal:
mkdir case-files
ls -ld describe el propio directorio: -l solicita una salida detallada y -d evita que se enumere su contenido:
ls -ld case-files
La salida incluye caracteres de permisos, un propietario y un grupo. Inicialmente el propietario es kali. El primer carácter d significa directorio. Las nueve posiciones siguientes forman tres grupos de bits de lectura (r), escritura (w) y ejecución (x) para propietario, grupo y otros. En un directorio, lectura permite listar nombres, escritura permite cambiar entradas y ejecución permite atravesarlo para acceder a las entradas.
chown cambia la propiedad. La forma user:group asigna tanto propietario como grupo; se necesita autoridad de administrador para transferir la propiedad a otra cuenta:
sudo chown practice-analyst:practice-analyst case-files
chmod cambia los permisos. En forma numérica, lectura vale 4, escritura 2 y ejecución 1. La suma 7 concede las tres; 0 no concede ninguna. El modo 700 proporciona acceso completo al propietario y ningún acceso al directorio para el grupo ni otros:
sudo chmod 700 case-files
ls -ld case-files
El principio debe indicar drwx------ y el propietario y grupo deben ser practice-analyst. Las fechas y los tamaños numéricos pueden variar. La propiedad elige qué cuenta recibe los permisos del propietario; el modo define entonces el acceso concedido a cada categoría.
Prueba el acceso como la cuenta prevista
En este paso comprobarás el acceso utilizando identidades de usuario reales en lugar de basarte únicamente en una lista de permisos.
sudo -u NAME ejecuta un comando como el usuario indicado en lugar de root. Utiliza al propietario del caso para crear un archivo en su directorio privado:
sudo -u practice-analyst touch /home/labex/project/case-files/checked.txt
No se espera salida. Inspecciona el resultado como la misma cuenta:
sudo -u practice-analyst ls -l /home/labex/project/case-files
El archivo vacío checked.txt debe pertenecer a practice-analyst. Su creación demuestra que esta cuenta puede atravesar el directorio y escribir en él.
La cuenta normal de Kali no debe tener ese acceso. Se espera que el siguiente comando falle con un mensaje de permiso denegado, demostrando la restricción. Continúa después del error:
ls /home/labex/project/case-files
Root aún puede inspeccionar el directorio mediante un comando autorizado explícitamente:
sudo ls /home/labex/project/case-files
Deberías ver checked.txt. Los permisos privados restringen las cuentas normales; root conserva la autoridad administrativa. Sigue utilizando kali para el trabajo normal y eleva solo la operación concreta que lo requiera. Ninguno de estos comandos modifica la cuenta del estudiante del host ni la forma en que LabEx se conecta a la VM.
Resumen
Inspeccionaste identidades de usuario, utilizaste sudo para acciones administrativas concretas, creaste una cuenta y asignaste propiedad y permisos a un directorio. Confirmaste que la cuenta prevista podía trabajar mientras que a otra cuenta normal se le denegaba el acceso.
