O comitê técnico responsável por tomar decisões finais sobre questões técnicas controversas no projeto Debian aprovou uma alteração no pacote do systemd, que muda o comportamento ao trabalhar com o diretório /var/lock. O gerenciador de sistema systemd, a partir da versão 258, restringiu a gravação no diretório /var/lock apenas para usuários com permissões de root, enquanto o comitê técnico do Debian concordou em manter o comportamento anterior, permitindo a gravação em /var/lock para qualquer usuário.
As regras do projeto Debian prescrevem a preservação do comportamento original das aplicações (configurações definidas upstream) ao criar pacotes. Para realizar alterações específicas do Debian em pacotes que contornam as regras do projeto, é necessária a obtenção de uma permissão especial do comitê técnico.
No caso do systemd, o comitê apoiou a proposta de não seguir a alteração que modificava as permissões de acesso ao /var/lock com o objetivo de aumentar a segurança, pois a capacidade de gravação pública no diretório /var/lock é mencionada na especificação FHS (Filesystem Hierarchy Standard) e é necessária para a continuidade do funcionamento de alguns programas existentes. Por exemplo, aplicações que operam em portas seriais, como uucp, minicom, mgetty+sendfax e hylafax, utilizam o diretório /var/lock para gerenciar o acesso a dispositivos /dev/ttyS* através da criação de arquivos de bloqueio.
A necessidade de limitar o acesso ao diretório /var/lock é explicada pelos desenvolvedores do systemd como uma proteção contra ataques DoS. O diretório /var/lock é um link simbólico para o diretório /run/lock. A partição com o diretório /run geralmente é montada separadamente via tmpfs, e a capacidade de gravação desenfreada pode ser utilizada para encher a partição e bloquear a criação de novos arquivos na hierarquia /run.
Para evitar a ocorrência de tais ataques com acesso irrestrito, anteriormente no Debian, um patch era utilizado para montar /run/lock em uma pequena partição tmpfs separada. No ano passado, esse patch foi substituído pela unidade run-lock.mount, e neste verão essa unidade foi removida, fazendo com que /run/lock estivesse na partição /run. Nos comentários da decisão do comitê técnico, o ex-mantenedor do systemd recomendou que não se esquecessem da alteração mencionada e voltassem a montar /run/lock separadamente, e a longo prazo, transferissem todos os aplicativos que dependem de /run/lock para bloqueios utilizando o mecanismo flock.
Fonte: opennet.ru
