Como as permissões de arquivo funcionam para o usuário "root"?

28

Eu tenho o seguinte arquivo:

---------- 1 Steve Steve 341 2017-12-21 01:51 myFile.txt

Troquei o usuário rootno terminal e percebi os seguintes comportamentos:

  • Eu posso ler este arquivo e escrever nele.

  • Não consigo executar este arquivo.

  • Se eu definir o xbit nas permissões de usuário ( ---x------) ou permissões de grupo ( ------x---) ou outras permissões ( ---------x) do arquivo, seria possível executá-lo.

Alguém pode me explicar ou me indicar um tutorial que explica todas as regras que se aplicam quando o rootusuário está lidando com arquivos e diretórios?

Steve
fonte

Respostas:

38

O acesso privilegiado a arquivos e diretórios é realmente determinado pelos recursos, não apenas por ser rootou não. Na prática, rootgeralmente possui todos os recursos possíveis, mas há situações em que todos / muitos deles podem ser descartados ou alguns dados a outros usuários (seus processos).

Em resumo, você já descreveu como as verificações de controle de acesso funcionam para um processo privilegiado. Veja como os diferentes recursos realmente o afetam:

A principal capacidade aqui éCAP_DAC_OVERRIDE um processo que pode "ignorar a leitura, gravação e execução de verificações de permissão". Isso inclui ler e gravar em qualquer arquivo, além de ler, escrever e acessar diretórios.

Na verdade, ele não se aplica à execução de arquivos que não estão marcados como executáveis. O comentário emgeneric_permission ( fs/namei.c), antes do acesso procurar arquivos, diz que

Os DACs de leitura / gravação são sempre substituíveis. Os DACs executáveis ​​são substituíveis quando há pelo menos um conjunto de bits exec.

E o código verifica se há pelo menos um xbit definido se você estiver tentando executar o arquivo. Suspeito que seja apenas um recurso de conveniência, para impedir a execução acidental de arquivos de dados aleatórios e a obtenção de erros ou resultados ímpares.

De qualquer forma, se você puder substituir as permissões, poderá fazer uma cópia executável e executá-la. (Embora possa fazer a diferença na teoria para arquivos setuid de um processo era capaz de substituir permissões de arquivo ( CAP_DAC_OVERRIDE), mas não tem outras capacidades relacionadas ( CAP_FSETID/ CAP_FOWNER/ CAP_SETUID). Mas ter CAP_DAC_OVERRIDEpermite editar /etc/shadowe coisas assim, então é aproximadamente igual apenas tendo acesso root completo de qualquer maneira.)

Há também o CAP_DAC_READ_SEARCHrecurso que permite ler qualquer arquivo e acessar qualquer diretório, mas não para executar ou gravar neles; e CAP_FOWNERisso permite que um processo faça coisas que normalmente são reservadas apenas ao proprietário do arquivo, como alterar os bits de permissão e o grupo de arquivos.

A substituição do bit pegajoso nos diretórios é mencionada apenas em baixo CAP_FOWNER, portanto parece que CAP_DAC_OVERRIDEnão seria suficiente ignorar isso. (Isso daria a você permissão de gravação, mas geralmente em diretórios fixos você a possui de qualquer maneira e a +tlimita.)

(Eu acho que dispositivos especiais contam como "arquivos" aqui. Pelo menos generic_permission()só tem uma verificação de tipo para diretórios, mas não verifiquei fora disso.)


Obviamente, ainda existem situações em que nem os recursos o ajudarão a modificar arquivos:

  • alguns arquivos /proce /sys, como eles não são arquivos reais
  • SELinux e outros módulos de segurança que podem limitar a raiz
  • chattrimutável +ie anexa apenas +asinalizadores no ext2 / ext3 / ext4, os quais param o root e impedem também a renomeação de arquivos etc.
  • sistemas de arquivos de rede, nos quais o servidor pode fazer seu próprio controle de acesso, por exemplo, root_squashnos mapas NFS raiz de ninguém
  • FUSE, que eu suponho que poderia fazer qualquer coisa
  • montagens somente leitura
  • dispositivos somente leitura
ilkkachu
fonte
Surpreendente que o comentário do arquivo de origem não pareça espelhado na capabilities(7)página de manual - considere arquivar um relatório de erro!
Toby Speight
@ilkkachu Como foi mostrado, roottenha rw-permissões em (quase) qualquer arquivo e, para obter a xpermissão, o xbit deve ser definido nas permissões de usuário / grupo / outros no arquivo. Mas e os diretórios, ele roottem rwxpermissões em qualquer diretório (mesmo que um diretório não tenha permissões ( ----------))?
Joseph
@ Joseph, sim, CAP_DAC_OVERRIDEpermite substituir todas as permissões de diretório, para que você leia, escreva e acesse diretórios (ou seja, liste o conteúdo, crie e desvincule arquivos). O comentário que citei sobre exec bit está no contexto de arquivos (apenas).
Ilkkachu
11

É exatamente como você notou nas permissões padrão:

  • Leitura e gravação:
    por padrão, o usuário root pode acessar qualquer arquivo no sistema. Você pode remover esse acesso alterando atributos como explicado aqui: chattr . Isso é então vinculado aos recursos.

  • Executar: o
    usuário raiz não tem permissão de execução, a menos que pelo menos um dos bits de execução esteja definido.

Kevin Lemaire
fonte
É possível ter arquivos que o root não pode gravar ou excluir. Portanto, "o usuário root pode acessar qualquer arquivo no sistema". está incorreto.
Lukas Boersma
Você quer dizer como sistema de arquivos somente leitura? ou você tem outro caso?
precisa
1
Estou falando de casos como estes: arquivos não
Lukas Boersma
5

O myFile.txté obtido por chmod 000 myFile.txt.

0 no permission
1 execute
2 write
3 execute + write
4 read 
5 read + execute
6 read + write
7 all

--------- significa que não há permissão para usuário, grupo e outros.

O usuário root possui um recurso irrestrito para modificar este arquivo. A leitura / gravação é concedida. Para executar este arquivo, o usuário root precisa torná-lo executável de qualquer maneira. (chmod 100, 010 ou 001)

GAD3R
fonte
2

O modo de execução é tratado um pouco diferente dos outros modos.

Permissões de leitura e gravação são usadas para impor políticas de segurança. O rootusuário geralmente é imune a restrições de segurança (existem algumas exceções, como arquivos imutáveis, e recursos modernos como recursos tornaram isso mais refinado), e é por isso que outro nome para essa conta é "superusuário".

Permissão de execução é mais um modo de aviso, distinguir se o arquivo é destinado para ser executável ou é apenas dados. Por esse motivo, até o usuário root obedece - não faz sentido executar um arquivo de dados. Se nenhuma das permissões de execução estiver definida, o root não poderá executar o arquivo; se algum deles estiver definido, ele pode. Obviamente, como o root também tem permissão para alterar as permissões de qualquer arquivo, a conta pode tornar um arquivo executável se desejar (a menos que o sistema de arquivos seja somente leitura).

BTW, scripts são um caso interessante nisso. Scripts são arquivos de dados para o intérprete relevante. Se o script tiver uma #!linha, você poderá executá-lo como um programa - o intérprete nomeado no shebang é executado com o nome do arquivo do script como argumento. Mas isso só será feito quando a permissão de execução estiver definida. Por outro lado, você pode executar o intérprete diretamente, por exemplo /bin/bash scriptname. Os intérpretes só se importam se conseguem ler o arquivo, não verificam as permissões de execução.

Barmar
fonte
1

Deixe-me explicar você teoricamente.

usuário root é o rei do sistema operacional.

Se um arquivo ou diretório tiver alguma permissão como X para executar, mas nada mais e alguém como o usuário Steve tiver o arquivo, o root também poderá executá-lo.

Lembre-se sempre, no Linux root pode fazer qualquer coisa, não há restrições no root.

Hassan Sohail
fonte
Nada. Se um arquivo tiver um atributo imutável , por exemplo, nem mesmo o root poderá alterá-lo (a menos que ele remova explicitamente esse atributo).
Ruslan
@Ruslan sim, mas é um caso excepcional demais, ele é novo, então eu o explico como básico, por padrão, esses tipos de atributos não ocorrem.
Hassan Sohail