Auditoría y asignación de permisos NTFS/ext4 en carpetas compartidas

Objetivo:

Comprender, auditar y configurar el sistema de permisos tradicionales de Linux (propietarios, grupos y permisos de acceso mediante octales/símbolos) y el uso de máscaras de creación de archivos (umask) para garantizar la seguridad y privacidad en carpetas compartidas.

Escenario:

  • Herramientas: Terminal Linux, chmod, chown, chgrp, umask, ls -l.
  • Conceptos analizados: Modelo de seguridad DAC (Discretionary Access Control), representación octal de permisos (lectura, escritura, ejecución), bits especiales (SUID, SGID, Sticky Bit) y control predeterminado de creación de ficheros.
  • Proceso clave: Creación de un entorno compartido multiusuario simulado, asignación estricta de propietarios, modificación de permisos de acceso en directorios y comprobación práctica de la máscara umask.

Escenario Real: Fuga de información en un directorio compartido de oficina

En una empresa, los empleados utilizan un directorio común en el servidor para intercambiar documentación. Debido a una mala configuración inicial de los permisos y de la máscara del sistema, cualquier usuario puede leer, modificar o incluso borrar los archivos confidenciales creados por sus compañeros de otros departamentos. Como administrador de sistemas, debes auditar el árbol de directorios y aplicar una política de permisos restrictiva basada en roles y grupos.

En los sistemas de archivos compatibles con POSIX (como ext4), la seguridad básica se sustenta en tres entidades: el propietario (user), el grupo principal o secundario (group) y el resto del mundo (others). Cada uno de ellos dispone de permisos independientes de Lectura (r = 4), Escritura (w = 2) y Ejecución (x = 1). NOTA: A diferencia de los permisos heredados avanzados de NTFS en entornos Windows, los permisos tradicionales de Linux en sistemas ext4 (sin contar ACLs) se aplican de forma directa sobre inodos y directorios, requiriendo especial atención al bit de ejecución (x) en carpetas, ya que sin él ningún usuario podrá entrar ni listar el contenido del directorio aunque tenga permisos de lectura.

Instrucciones:

Fase 1: Preparación del entorno y usuarios de prueba:

  • Crear un directorio raíz para la práctica de permisos compartidos:
    • mkdir -p ~/auditoria_permisos/carpeta_compartida
    • cd ~/auditoria_permisos
  • Crear dos usuarios del sistema simulados (ej. empleado1 y empleado2) y un grupo de trabajo común (ej. departamento):
    • sudo groupadd departamento
    • sudo useradd -m -G departamento empleado1
    • sudo useradd -m -G departamento empleado2

Fase 2: Auditoría y cambio de propietarios y grupos (chown / chgrp):

  • Asignar la propiedad del directorio compartido al usuario empleado1 y el grupo al equipo departamento: 
    sudo chown -R empleado1:departamento carpeta_compartida/
  • Desglose del comando:
    • -R (recursive): Aplica el cambio de propietario y grupo a todos los archivos y subdirectorios internos.
    • empleado1:departamento: Define el nuevo usuario propietario (antes de los dos puntos) y el nuevo grupo asignado (después).
  • Verificar el cambio de propietarios ejecutando un listado detallado: ls -l

Fase 3: Configuración de permisos estrictos mediante notación octal (chmod):

  • Queremos que el propietario tenga control total (7), el grupo del departamento pueda leer y escribir (6), y el resto de usuarios del sistema no tengan ningún acceso (0).
  • Aplicar los permisos mediante el comando chmod: 
    sudo chmod -R 760 carpeta_compartida/
  • Desglose de la notación octal:
    • 7 (Propietario): Lectura (4) + Escritura (2) + Ejecución (1) = 7.
    • 6 (Grupo): Lectura (4) + Escritura (2) = 6.
    • 0 (Otros): Sin ningún permiso de acceso (0).
  • Inspeccionar los permisos resultantes mediante: ls -ld carpeta_compartida

Fase 4: Análisis y prueba del comportamiento de la máscara Umask:

  • El comando umask determina qué permisos se descuentan por defecto al crear nuevos archivos o directorios.
  • Comprueba tu umask actual ejecutando simplemente: umask (por defecto suele ser 0022 o 0002).
  • Crear un archivo de prueba dentro de la carpeta compartida y observar sus permisos predeterminados: 
    touch carpeta_compartida/prueba_umask.txt
    ls -l carpeta_compartida/prueba_umask.txt
  • Modificar temporalmente la máscara de seguridad para que los nuevos archivos sean totalmente privados (restringiendo lectura y escritura al grupo y otros): 
    umask 0077
  • Crear un nuevo archivo de prueba y comprobar cómo ahora se restringen drásticamente los permisos base: 
    touch carpeta_compartida/prueba_privada.txt
    ls -l carpeta_compartida/prueba_privada.txt
  • Restaurar la máscara predeterminada de la sesión: umask 0022

Verificación:

  • Ejecutar un listado recursivo completo para auditar el estado final de todos los archivos creados y comprobar que la estructura de permisos y propietarios es coherente con la política de seguridad establecida: ls -lR carpeta_compartida/

Posibles errores y resolución de problemas:

Si al configurar una carpeta compartida notas que los usuarios del grupo pueden leer los archivos pero no consiguen crear nuevos ficheros ni entrar en las subcarpetas, se debe a una falta de permisos críticos en el directorio contenedor.

  • Solución: Asegúrate de otorgar siempre el bit de ejecución (x) tanto a nivel de propietario como de grupo en los directorios (por ejemplo, aplicando chmod 770), ya que sin el permiso de ejecución en directorios el sistema bloquea cualquier intento de navegación o escritura interna.

Preguntas de reflexión:

  1. ¿Qué diferencia fundamental existe entre los permisos asignados a un archivo de texto plano frente a los mismos permisos aplicados sobre un directorio en Linux?
  2. ¿Cómo se calcula el valor resultante de los permisos de un archivo nuevo si la máscara del sistema (umask) está configurada en 0027?
  3. ¿Qué función cumple exactamente el bit de ejecución (x) cuando se configura sobre una carpeta compartida en un sistema de archivos ext4?
  4. ¿Por qué el modelo de permisos tradicionales POSIX (DAC) se queda corto en entornos empresariales complejos y qué alternativa avanzada se utiliza habitualmente?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué diferencia fundamental existe entre los permisos asignados a un archivo de texto plano frente a los mismos permisos aplicados sobre un directorio en Linux?

En un archivo de texto, el permiso de lectura (r) permite ver su contenido, el de escritura (x) modificarlo, y el de ejecución (x) ejecutarlo como programa. En cambio, en un directorio, el permiso de lectura (r) solo permite listar los nombres de los archivos contenidos, el de escritura (w) permite crear, borrar o renombrar archivos dentro de él, y el de ejecución (x) es indispensable para poder acceder, atravesar o consultar los metadatos de los ficheros de su interior.

2. ¿Cómo se calcula el valor resultante de los permisos de un archivo nuevo si la máscara del sistema (umask) está configurada en 0027?

Los permisos base estándar con los que se crea un archivo en Linux son 666 (lectura y escritura para todos, sin ejecución por seguridad). La máscara umask actúa restando bits mediante una operación lógica de negación (bitwise NOT). Restando 027 a 666, el resultado final para los nuevos archivos será 640 (el propietario tiene lectura y escritura 6, el grupo tiene solo lectura 4, y los otros usuarios no tienen ningún permiso 0).

3. ¿Qué función cumple exactamente el bit de ejecución (x) cuando se configura sobre una carpeta compartida en un sistema de archivos ext4?

En un directorio, el bit de ejecución otorga el derecho de acceso o "búsqueda" (search permission). Sin este bit activo, ningún usuario puede entrar en la ruta de la carpeta ni acceder a los archivos que contiene, incluso aunque disponga de permisos explícitos de lectura (r) sobre los ficheros internos.

4. ¿Por qué el modelo de permisos tradicionales POSIX (DAC) se queda corto en entornos empresariales complejos y qué alternativa avanzada se utiliza habitualmente?

El modelo tradicional solo permite asignar una única terna de permisos para el propietario, otra para un único grupo y otra para el resto, lo cual es demasiado rígido cuando múltiples usuarios de diferentes departamentos necesitan permisos específicos y dispares sobre los mismos archivos. Para solventar esta limitación se emplean las Listas de Control de Acceso (ACLs - Access Control Lists), que permiten otorgar permisos granulares a usuarios y grupos adicionales de forma independiente.