El comité técnico que toma decisiones finales sobre temas técnicos controvertidos en el proyecto Debian ha aprobado un cambio en el paquete de systemd que modifica el comportamiento en relación con el directorio /var/lock. A partir de la versión 258, el gestor de sistemas systemd ha limitado la capacidad de escritura en el directorio /var/lock únicamente a los usuarios con privilegios de root, mientras que el comité técnico de Debian ha aprobado mantener el comportamiento anterior que permite la escritura en /var/lock a cualquier usuario.
Las reglas del proyecto Debian estipulan que se debe conservar el comportamiento original de las aplicaciones (configuraciones establecidas en upstream) al crear paquetes. Para realizar cambios específicos de Debian en los paquetes que van en contra de las reglas del proyecto, se necesita obtener un permiso especial del comité técnico.
En el caso de systemd, el comité apoyó la propuesta de no seguir el cambio que altera los permisos de acceso a /var/lock con el objetivo de aumentar la seguridad, ya que la posibilidad de escritura pública en el directorio /var/lock se menciona en la especificación FHS (Filesystem Hierarchy Standard) y es necesaria para el funcionamiento continuo de algunos programas existentes. Por ejemplo, aplicaciones que trabajan en puertos serie, como uucp, minicom, mgetty+sendfax y hylafax, utilizan el directorio /var/lock para gestionar el acceso a los dispositivos /dev/ttyS* mediante la creación de archivos de bloqueo.
La necesidad de restringir el acceso al directorio /var/lock es explicada por los desarrolladores de systemd como una protección contra ataques de DoS. El directorio /var/lock es un enlace simbólico al directorio /run/lock. La sección con el directorio /run generalmente se monta por separado mediante tmpfs, y la posibilidad de escritura incontrolada en él puede utilizarse para llenar la sección y bloquear la creación de nuevos archivos en la jerarquía /run.
Para evitar ataques similares con acceso ilimitado, anteriormente se utilizaba un parche en Debian que montaba /run/lock en una pequeña partición tmpfs. El año pasado, este parche fue reemplazado por el módulo run-lock.mount, y este verano, dicho módulo fue eliminado, después de lo cual /run/lock quedó en la partición /run. En los comentarios de la decisión del comité técnico, el ex mantenedor de systemd recomendó no olvidar este cambio y volver a montar /run/lock por separado, y a largo plazo, trasladar todas las aplicaciones que dependen de /run/lock a bloqueos mediante el mecanismo flock.
Fuente: opennet.ru
