É um processo com uid efetivo ou real sendo root ainda sujeito a permissão de bits de um arquivo ao acessar o arquivo?

Question

De link

In Unix and Linux there are two levels of permissions: standard user and superuser (usually called root).

The standard user has access only to the files that he has permissions for, by ownership, group membership or ACL.

The superuser has permissions to everything (we'll ignore stuff like SELinux and the like for this answer) without limits within the userspace.

Quando um processo tem um uid eficaz ou real sendo root e tenta acessar um arquivo, ele ainda está sujeito a bits de permissão do arquivo? Ou como a citação diz (se eu entendi corretamente), ter euid root irá substituir os bits de permissão do arquivo?

Por exemplo,

• quando o proprietário do arquivo não é root e seu grupo não corresponde ao grupo efetivo ou a grupos suplementares do processo, Os bits de permissão do arquivo para "outros" serão aplicados ao processo? Se o arquivo não permitir que outras pessoas leiam ou escrevam ou executem, o processo ainda pode ler ou escrever ou executar?

• quando o proprietário do arquivo é raiz, e os bits de permissão do arquivo para "usuário" não permitem leitura, gravação ou execução, o processo ainda pode ler, gravar ou executar o arquivo?

É possível fazer um processo com uid efetivo ou real sendo o root incapaz de acessar um arquivo? Por exemplo, alterando os bits de permissão do arquivo?

Obrigado.

    

Answer 1

No Unix tradicional, root pode fazer qualquer coisa.

No entanto, no Linux moderno (talvez outros Unixes), agora ele tem recursos. A capacidade discutida aqui é CAP_DAC_OVERRIDE , qualquer processo com esse recurso ignorará as permissões de arquivo (com exceção de x , consulte outras respostas).

A maioria dos sistemas será configurada no modo compatível com versões anteriores, para que quando um processo altera seu ID de usuário efetivo para root, ele obtém todos os recursos e, quando o ID de usuário efetivo muda de root, ele elimina os recursos.

Existem maneiras de evitar o descarte de recursos. Isso pode ser usado para transmitir alguns recursos para um processo não-raiz. Há também uma maneira de obter recursos sem tornar-se raiz, isso funciona de maneira semelhante a como um processo se torna raiz.

É o ID do usuário efetivo, o que importa, os IDs de usuário reais e salvos apenas dão permissão para copiar esses IDs para um dos outros IDs (por exemplo, para o ID de usuário efetivo).

SE_linux e namespaces / cgroups, podem restringir o que o root pode fazer.

    

Answer 2

A raiz terá acesso a tudo, independentemente dos bits de permissão. Uma exceção é que um processo raiz não tentará executar um arquivo se nenhum dos bits de execução estiver configurado e restrições forem definidas pelo SELinux.

No entanto, o root ainda poderá definir os bits de execução desejados e alterar as regras do SELinux, portanto não há nada que você possa fazer para impedir que o root acesse seus arquivos.

Editar

De "man path_resolution"

On a traditional UNIX system, the superuser (root, user ID 0) is all-powerful, and bypasses all permissions restrictions when accessing files.

    

Answer 3

When a process has an effective or real uid being root and tries to access a file...

É apenas o UID efetivo que é importante para o acesso ao sistema de arquivos, não para o UID real. Um processo que mantém um UID privilegiado pode embaralhar os UIDs reais e efetivos para eliminar temporariamente os privilégios.

# perl -MEnglish -e '$EUID = 65534; system "id"; system "cat /etc/shadow"'
uid=0(root) gid=0(root) euid=65534(nobody) groups=0(root)
cat: /etc/shadow: Permission denied

Mas além disso, você está certo, ter privilégios permite acessar arquivos independentemente dos bits de permissão. (Além do fato de que executar um arquivo não funciona a menos que tenha pelo menos um x bit definido, mas isso não é nada além de uma conveniência. Se você é privilegiado, normalmente você pode simplesmente copiar o arquivo e executá-lo ou altere as permissões primeiro.)

Ver, por exemplo, a parte final da página man do Linux path_resolution(7) ("Ignorando verificações de permissões: superusuário e recursos ") ou o texto em POSIX (" 4.5 Permissões de Acesso a Arquivos ") .

Como as últimas dicas, e os primeiros estados em linguagem simples, a verificação real de ser privilegiado pode ser diferente de apenas o UID. No Linux, na verdade, é o CAP_DAC_OVERRIDE capacity (ou CAP_DAC_READ_SEARCH para um menor extensão). Eu não sei os detalhes de outros sistemas.

    

Answer 4

Você não pode ocultar nada do root , a menos que você use criptografia, e mesmo assim o root ainda poderá deletá-lo!

Desculpe! ¯ \ _ (ツ) _ / ¯

    

Answer 5

Para o usuário privilegiado, apenas o x bit é avaliado.

Isso significa que, para permitir que o super usuário execute um arquivo, pelo menos um x bit deve ser definido.

Todas as outras permissões são ignoradas para o superusuário.