Una de las tareas claves dentro de la gestión de archivos críticos del sistema y registros de eventos (logs) es garantizar la integridad de los mismos (Req. 10.5 y específicamente 10.5.2). En el caso de los logs, cualquier modificación no autorizada puede hacer que un log pierda su validez probatoria y por ende su valor tácito como evidencia. Cuando el log es almacenado en un medio magnético y se emplean únicamente los clásicos permisos de lectura, escritura y ejecución no se logra el nivel de protección requerido.  Igual sucede cuando se tiene un archivo crítico al cual se quiere proteger para evitar una modificación o su eliminación.

Para ello, muchos de los sistemas de archivos (filesystems) actuales cuentan con funcionalidades adicionales (o “atributos extendidos”) que permiten gestionar de una forma más detallada los permisos y acciones a realizar sobre un archivo específico.  Estas características a nivel de filesystem permiten definir controles de acceso (ACL) granulares más allá de los permisos normales. Para el caso específico de logs, se analizarán las funcionalidades “Append-Only” e “Immutability”, que se pueden aplicar sobre este tipo de archivos ya sea si son online u offline:

  • Log online: Partiendo del principio que un log online (esto es, que se encuentran registrando eventos) es un archivo que solamente agrega líneas nuevas al final  como si fuera una especie de pila de la cual no se pueden retirar entradas ya ingresadas, la única acción que se requiere es precisamente esa: anexar nuevas entradas al final sin modificar el contenido que ya se tenía previamente. Esta funcionalidad es conocida como “Append-Only” (solo anexar)
  • Log offline: Cuando el archivo de log pasa a ser archivado (log offline, que no registra eventos), se requiere que no pueda ser modificado y preferiblemente inmutable (que  no pueda ser ni leído, ni modificado ni eliminado), lo cual garantizará su integridad mientras es almacenado (req. 10.7).

Como ejemplo, a continuación se describe la implementación de dichas funcionalidades en dos tipos de filesystems: EXT para Linux y UFS/FFS para sistemas BSD.

Filesystems EXT

Más allá del ya conocido comando “chmod” empleado para la gestión de permisos de acceso discrecionales sobre archivos (lectura, escritura y ejecución para grupos y usuarios), los filesystem EXT (EXT2, EXT3 y EXT4) permiten realizar una asignación de permisos mucho más granular, conocida como “atributos extendidos”, dentro de los cuales encontramos los flags “Append-only” e “Immutable” (entre otros). Estos permisos pueden ser asignados directamente a archivos o carpetas y es una acción que únicamente puede realizar un usuario administrador o un proceso que cuente con los permisos necesarios (CAP_LINUX_IMMUTABLE y CAP_LINUX_IMMUTABLE).

La asignación de estos atributos extendidos se realiza mediante el comando “chattr”. Para el caso de archivos de log, los flags que se pueden emplear son los siguientes:

a: append only

Mediante la asignación de este flag a un archivo en específico, el archivo únicamente permitirá anexar contenido nuevo, sin modificar el contenido existente.

i: immutable

Con este flag el archivo no podrá ser eliminado ni renombrado, no se podrán crear links a este archivo y se bloqueará cualquier escritura sobre el mismo.

Para listar los atributos extendidos de un archivo o carpeta en particular, se emplea el comando “lsattr”.

Filesystems UFS/FFS

Originalmente las funcionalidades de “Append-only” e “Immutability” fueron implementadas en sistemas BSD 4.4. La gestión de estos atributos extendidos se realiza con el comando “chflags” con los siguientes flags:

System Change flag (schg)

Este flag previene que los ficheros sean movidos, cambiados o eliminados (inmutabilidad). Solamente puede ser habilitado por root y no puede ser removido si el sistema se encuentra ejecutándose en SecureLevel 1 o superior.

User Change flag (uchg)

Este flag actúa igual que el anterior, salvo que el dueño del fichero y root pueden habilitarlo o deshabilitarlo.

System append-only flag (sappnd)

Este flag previene que los archivos sean modificados, de forma muy similar a como lo hace el flag immutable, con la única excepción que los datos pueden ser añadidos al final del fichero. Esta característica es útil en ambientes de gestión de ficheros de registro (logs) o en ficheros .history, en los cuales se quiere que se añada información pero que no se modifiquen los datos que estaban previamente. Es importante tener en cuenta que cuando se aplica este flag, el archivo no puede ser eliminado.

User append-only flag (uappnd)

Igual que el anterior, con la única diferencia que éste flag puede ser deshabilitado por el dueño del archivo o por root en cualquier momento, sin importar el securelevel en el que esté el sistema. Esta característica es útil cuando se quiere permitir que los usuarios puedan usar este nivel de protección en sus propios archivos.

System no unlink flag (sunlnk)

Este flag previene la eliminación de un fichero y únicamente puede ser habilitado por root cuando el security level es superior a 0.

User no unlink flag (uunlnk)

Este flag le permite a un usuario indicarle al sistema que un fichero no debe ser eliminado, independientemente de sus permisos Unix tradicionales o los permisos de su directorio padre. Puede ser habilitado/deshabilitado por el usuario o por root.

Para visualizar los permisos efectivos de un archivo con atributos extendidos se usa el comando “ls -lO”.

 Conclusión: Muchas veces los permisos discrecionales típicos (lectura, escritura y ejecución) no son suficientes para ofrecer una protección idónea a determinados archivos críticos y/o archivos de registro de eventos (logs). Es aquí en donde entra el valor agregado de los atributos extendidos en filesystems EXT (Linux) y UFS/FFS (BSD), permitiendo utilizar funcionalidades como “append-only” o “immutability” como una capa adicional de protección y control en el cumplimiento del requisito 10 de PCI DSS.