O superusuário pode gravar em arquivos somente leitura?

Eu me deparei com um surpreendente (para mim) comportamento de permissão no FreeBSD. Digamos que estou operando como usuário não root . Crio um arquivo, defino sua permissão como somente leitura e, em seguida, tento gravar nele:

$ touch f
$ chmod 400 f
$ ls -l f
-r--------  1 user  wheel  f
$ echo a >> t
t: Permission denied.

Por enquanto, tudo bem. Agora eu faço o mesmo que root e ele grava no arquivo:

# ls -l f2
-r--------  1 root  wheel  f2
# echo a >> f2
# echo $?
0

É um bug ou comportamento pretendido? Posso assumir com segurança que isso funcionaria assim em qualquer Unix e Linux?

files permissions root arrowd
fonte

Qualquer usuário com CAP_DAC_OVERRIDEpode fazer isso. Em quase todos os sistemas Linux, isso significa que o root pode fazer isso, sendo intencional. Não posso falar pela parte do FreeBSD, mas imagino que eles tenham uma configuração semelhante.

Bratchley

O motivo pelo qual a raiz SEMPRE precisa gravar em um arquivo é porque, nos sistemas tradicionais de arquivos unix (ext4, zfs etc.), as permissões de arquivo fazem parte do arquivo. Portanto, se o root não puder gravar em um arquivo, NINGUÉM poderá tornar o arquivo somente leitura gravável novamente, porque chmodnão poderá gravar no arquivo.

Slebetman 17/08/16

@slebetman Você não precisa ter acesso de gravação a um arquivo para atualizar as permissões. Apenas tente touch somefile; chmod 0000 somefile; chmod 0644 somefilecomo um usuário normal.

user253751

@immibis: Que você possui. Necessidades de raiz para ser capaz de alterar as permissões em arquivos que ele não possui

slebetman

@slebetman Sim ... mas você estava falando sobre alterar permissões em arquivos para os quais não pode escrever, não sobre alterar permissões em arquivos que você não possui.

user253751

Respostas:

É normal rootpoder substituir permissões dessa maneira.

Outro exemplo é roota capacidade de ler um arquivo sem acesso de leitura:

$ echo hello > tst
$ chmod 0 tst
$ ls -l tst
---------- 1 sweh sweh 6 Aug 16 15:46 tst
$ cat tst
cat: tst: Permission denied
$ sudo cat tst
hello

Alguns sistemas têm o conceito de arquivos imutáveis . por exemplo, no FreeBSD:

# ls -l tst
-rw-r--r--  1 sweh  sweh  6 Aug 16 15:50 tst
# chflags simmutable tst
# echo there >> tst
tst: Operation not permitted.

Agora nem mesmo é rootpossível gravar no arquivo. Mas, é claro, rootpode remover a bandeira:

# chflags nosimmutable tst
# echo there >> tst
# cat tst
hello
there

Com o FreeBSD, você pode dar um passo adiante e definir uma flag de kernel para impedir a rootremoção da flag:

# chflags simmutable tst
# sysctl kern.securelevel=1
kern.securelevel: -1 -> 1
# chflags nosimmutable tst
chflags: tst: Operation not permitted

Agora ninguém, nem mesmo rootpode mudar este arquivo.

(O sistema precisa ser reiniciado para reduzir o nível de segurança).

Stephen Harris
fonte

Como a exigência de reinicialização é uma medida de segurança eficaz? Além disso, se o root é root e pode fazer qualquer coisa, por que se preocupar em impedir que o root faça o que o root deseja?

gato

Em um sistema seguro, a raiz não é semelhante a Deus. O FreeBSD securelevel é uma pequena tentativa de tornar a raiz menos semelhante a Deus. O nível de segurança pode ser definido como o padrão 1 na configuração do sistema, para permanecer ativo mesmo após uma reinicialização. Portanto, seria necessário acesso ao console e modo de usuário único e isso é muito evidente. Existe um ensaio inteiro sobre a segurança do Unix que é demais para um campo de comentários do SE, mas estamos tentando passar de um modelo de 'acesso root com acesso total' para algo mais sutil. Tentamos aplicar onde for possível (por exemplo, nível de segurança) e detectar onde não (evidência de reinicialização, trilhas de auditoria).

Stephen Harris

FWIW, no Linux chattr +i tstdefine atributo imutável .

Ruslan

Sim, isso é muito normal. root não tem limites de leitura / gravação (com muito pouca exceção), porque ele é a raiz.

Ipor Sircer
fonte