Início / unix / Perguntas / 503111
Accepted
mxmehl
Asked: 2019-02-27 03:11:48 +0800 CST

Permissões de grupo para root não funcionando em /tmp

  • 772

Eu experimento um comportamento estranho no meu diretório /tmp. Embora um usuário pertença a um grupo tenha permissão para ler/escrever um arquivo, ele não pode fazê-lo.

Neste exemplo, crio um novo arquivo /tmp/test.txtcomo user max. Eu dou as permissões 777 e faço o arquivo pertencer ao grupo root, mas o usuário rootainda não pode editá-lo.

su max
touch /tmp/test.txt
chmod 777 /tmp/test.txt

su root
chown max:root /tmp/test.txt

# ls -l /tmp/test.txt 
-rwxrwxrwx 1 max root 0 26. Feb 12:08 test.txt

# echo "foobar" > /tmp/test.txt
bash: /tmp/test.txt: Permission denied

Ao mover test.txtpara um diretório diferente, tudo funciona conforme o esperado.

/tmpé um tmpfs montado via fstab através das seguintes opções:

tmpfs       /tmp    tmpfs   nodev,nosuid,size=5G    0 0

Ao executar ls -l /, a pasta tmp se parece com o seguinte:

drwxrwxrwt  20 root root   640 26. Feb 12:01 tmp/

Estou executando o Manjaro, um derivado do Arch Linux.

Eu fiz algo errado ao montar tmpfs?

arch-linux permissions

1 respostas

  1. Best Answer

    O comportamento que você está mostrando parece depender do fs.protected_regularparâmetro do kernel do Linux, introduzido junto com fs.protected_fifoseste commit (convergido na versão 4.19, acredito), com o objetivo de corrigir vulnerabilidades de segurança.

    Trecho da mensagem do commit (ênfase minha):

    namei: permite O_CREAT restrito de FIFOs e arquivos regulares

    Não permite a abertura de FIFOs ou arquivos regulares não pertencentes ao usuário em diretórios fixos graváveis, a menos que o proprietário seja o mesmo do diretório ou o arquivo seja aberto sem o sinalizador O_CREAT . O objetivo é tornar os ataques de falsificação de dados mais difíceis. ...

    A mesma mensagem de confirmação também relata uma lista de números de Vulnerabilidades e Exposições Comuns (CVE) relacionados.

    Assim, desde que userXseja rootou seja concedido acesso de gravação para /tmp/file, e que /tmpseja um diretório gravável mundial com o sticky bit definido, eles podem ser abertos filepara gravação somente se:

    • userXé proprietário de file; ou
    • ambos filee o diretório /tmpsão de propriedade do mesmo usuário.

    No seu teste, roottem permissões de escrita em /tmp/test.txt, mas não é o dono do arquivo, nem tem /tmp/test.txte /tmpo mesmo dono (respectivamente maxe root).

    O problema parece ser totalmente alheio à forma como /tmpé montado.

    A documentação relevante está em Documentation/sysctl/fs.txt :

    protected_fifos:

    A intenção dessa proteção é evitar gravações não intencionais em um FIFO controlado pelo invasor, onde um programa espera criar um arquivo regular.

    ...

    protegido_regular:

    Essa proteção é semelhante a protected_fifos, mas evita gravações em um arquivo regular controlado pelo invasor, onde um programa espera criar um.

    Quando definido como "0", a gravação em arquivos regulares é irrestrita.

    Quando definido como "1", não permite que o O_CREAT abra em arquivos regulares que não possuímos em diretórios fixos graváveis, a menos que sejam de propriedade do proprietário do diretório.

    Quando definido como "2", também se aplica a diretórios fixos graváveis ​​em grupo.

    Ou seja, a proteção descrita acima pode ser desabilitada com o comando:

    sysctl fs.protected_regular=0

    Um pouco de teste para apoiar nossa hipótese:

    $ su - root
# sysctl fs.protected_regular
fs.protected_regular = 1
# cd /
# mkdir test
# chmod 1777 test
# su - otheruser
$ echo hello >/test/somefile
$ exit
logout
# cat /test/somefile
hello
# ls -lah test/somefile
-rw-r--r-- 1 otheruser otheruser 6 Feb 26 17:21 test/somefile
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# sysctl fs.protected_regular=0
fs.protected_regular = 0
# echo root >>test/somefile
# cat /test/somefile
hello
root
# sysctl fs.protected_regular=1
fs.protected_regular = 1
# echo root >>test/somefile
-bash: test/somefile: Permission denied
# chmod 0777 /test/
# echo root >>test/somefile
# cat test/somefile 
hello
root
root

    Ao contrário de fs.protected_hardlinkse fs.protected_symlinks, fs.protected_regulare fs.protected_fifosnão são habilitados por padrão no código do kernel.
    Habilitá-los é uma mudança incompatível com versões anteriores (como o exemplo que você forneceu neste comentário aponta) e, até onde eu sei, systemdfiz isso na versão 241, com este commit recente .

    Créditos: obrigado ao JdeBP por apontar na direção certa com um comentário à pergunta.

    • 34

relate perguntas