Quais direitos de acesso o superusuário não pode violar?

Pe. Br. George disse em uma de suas palestras (em russo) que existem alguns direitos de acesso que o superusuário não pode violar. Ou seja, existem alguns direitos de acesso que podem proibir o superusuário de fazer alguma coisa.

Não consegui encontrar essas informações na Internet e estou curioso sobre o que são. Provavelmente, isso é algo relacionado à execução principal do sistema, não é? Talvez ele não consiga parar alguns processos do sistema? Ou talvez ele não possa executar um processo no modo real?

Esta questão não está relacionada ao SELinux (George estava falando sobre isso logo antes da pergunta).

acesso negado à raiz :

rootpode ser negado acesso direto à rede. Isso é útil em hosts conectados à Internet, pois exige que você efetue login como smith, então sudo.

algumas coisas que a raiz não pode fazer :

Isto não é por falta de privilégio. Não vejo nada que a raiz não possa fazer, no entanto, alguns problemas técnicos podem ser considerados "proibidos".

Sou root, por que não consigo criar / excluir esse arquivo, enquanto um usuário comum pode?

Você está em um compartilhamento NFS / samba e não recebeu access=autorização específica ( ). O usuário comum falha no direito comum. (veja raiz local vs remota abaixo)

Sou root, por que não consigo matar esse processo?

Há uma E / S pendente e a unidade física / LUN remoto foi desconectada, o processo só pode ser interrompido pela reinicialização.

Sou root, como obtenho a senha do archemar?

Você pode su - archemaracertar ou alterar a senha do archemar sem conhecer a senha anterior, mas não pode lê-la (exceto um key logger), pois as senhas são armazenadas usando um hash unidirecional.

raiz local vs remota

• Você pode fazer root na sua estação / PC e usar um compartilhamento NFS da empresa / faculdade / universidade / provedor.
• Em seguida, você pode ter apenas um login não raiz no computador que exporta o NFS.

Agora

cp /bin/bash /nfs/home/me/bash
chown root /nfs/home/me/bash
chmod u+s /nfs/home/me/bash

basta fazer logon no servidor NFS, executar ./bashe você é root no servidor da empresa / universidade.

No caso usual, isso está incorreto - o superusuário possui privilégios / permissões para qualquer funcionalidade fornecida pelo sistema (1). O local em que essa regra é quebrada é quando você joga o SELinux na mistura. Com o SELinux, é possível restringir até os privilégios de root para impedir certas ações. No entanto, as ações específicas não permitidas são altamente dependentes da configuração do SELinux da máquina local; portanto, mesmo com o SELinux, essa pergunta não pode ser respondida no sentido geral.

(1) - se um sistema não fornecer um determinado recurso, por exemplo, não houver funcionalidade do kernel em tempo real, estou considerando a declaração "o root não tem acesso a essa funcionalidade" como falsa, pois essa declaração depende de um suposição falsa (ou seja, que o recurso fornecido esteja disponível para qualquer pessoa nesse sistema)

Por um lado, existem coisas que nenhum usuário pode fazer, como

• diretórios com links físicos (devido às limitações do sistema de arquivos)
• gravando em um CD-ROM já gravado (porque a física)

Mas esses não são privilégios, porque não podem ser concedidos, simplesmente não são possíveis para ninguém.

Existem restrições para todo o sistema ou partes dele que podem ser ativadas ou desativadas.
Por exemplo, no OS X há uma opção para permitir a execução de código apenas se ele tiver sido assinado pela Apple.

Também não considero isso um privilégio real, porque nenhum usuário pode tê-lo se o superusuário não puder. Você só pode desativá-lo globalmente.

Edit:
Sua idéia de um arquivo sem o bit executável também se enquadra nessa categoria, pois literalmente ninguém é capaz de fazer isso, e ninguém pode receber essa permissão.
E mesmo ao conceder a outro usuário ou grupo a permissão para executar esse arquivo, mas não o root ou o grupo de usuários estiver ativo, o root ainda poderá executar esse arquivo (testado no servidor OS X 10.10, 10.11 e Ubuntu 15.04).

Além desses casos, quase não há nada que a raiz não possa fazer.
Existe, no entanto, uma coisa chamada modo kernel (em oposição ao modo usuário).

Até onde eu sei, em um sistema são, apenas o kernel, as extensões e os drivers do kernel são executados no modo kernel, e tudo o mais (incluindo o shell no qual você faz logon como root) é executado no modo do usuário.
Você poderia, portanto, argumentar que "ser raiz não é suficiente". No entanto, na maioria dos sistemas, o usuário root é capaz de carregar módulos do kernel, que por sua vez são executados no modo kernel, dando efetivamente ao root uma maneira de executar código no modo kernel.

No entanto, existem sistemas (como o iOS) onde isso não é possível (arbitrariamente), pelo menos não sem a exploração de todos os itens de segurança. Isso se deve principalmente ao aumento da segurança, como a imposição de assinatura de código.
Por exemplo, existem chaves de criptografia AES embutidas nos processadores do iDevices, que podem ser acessadas apenas no modo kernel. Os módulos do kernel poderiam acessá-los, mas o código nesses módulos também teria que ser assinado pela Apple para que o kernel os aceitas.

No OS X, desde a versão 10.11 (El Capitan), também existe o chamado "modo sem raiz" (embora o nome seja enganoso porque o root ainda existe), que proíbe efetivamente o root de certas coisas que os instaladores ainda podem fazer.
Citando esta excelente resposta no AskDifferent :

Aqui está o que restringe, mesmo a partir da raiz:

• Você não pode modificar nada em / System, / bin, / sbin ou / usr (exceto / usr / local); ou qualquer um dos aplicativos e utilitários integrados. Somente o instalador e a atualização de software podem modificar essas áreas e até mesmo fazem isso ao instalar pacotes assinados pela Apple.

A "execução do núcleo do sistema" que você mencionou está bem sob rootcontrole, por exemplo, através de módulos carregáveis ​​do kernel. Obviamente, isso pressupõe que o carregamento de módulos do kernel seja suportado pelo kernel; ninguém pode executar ações que não são viáveis, mesmo root.

O mesmo vale para os processos do sistema. roottem permissão para matar qualquer processo, mas é impossível parar um processo em execução no modo kernel sem comprometer a integridade do kernel, portanto, é simplesmente inviável interromper o processamento imediatamente. Observe que rootnão será negado o fim desses processos, o fato de se matar simplesmente não terá efeito.

Finalmente, o modo real: o kernel do Linux não tem suporte para isso; então, novamente, ninguém pode fazer o inviável, nem mesmo root.

A @Siguza mencionou a execução de arquivos sem a xpermissão, o que é bastante possível para o rootusuário:

/lib/ld-linux.so.2 /path/to/executable

Um exemplo poderia ser a modificação de arquivo imutável: Você pode definir um atributo de arquivo icom chattrque faz a imutável arquivo mesmo para o root. Por exemplo:

# whoami
root
# touch god
# chattr +i god
# rm god
rm: cannot remove ‘god’: Operation not permitted
# touch god
touch: cannot touch ‘god’: Permission denied

Observe que o arquivo aparece como arquivo gravável normal na ls -lsaída:

# ls -l god
-rw-r--r-- 1 root root 0 Oct 26 19:27 god

Para ver o iatributo, você precisa usar lsattr:

# lsattr god
----i----------- god

A página de manual do chattr indica o seguinte sobre o iatributo:

Um arquivo com o atributo `i 'não pode ser modificado: não pode ser excluído ou renomeado, nenhum link pode ser criado para esse arquivo e nenhum dado pode ser gravado no arquivo. Somente o superusuário ou um processo que possui o recurso CAP_LINUX_IMMUTABLE pode definir ou limpar esse atributo.

Porém, a raiz pode facilmente desfazer a imutabilidade:

# chattr -i god
# rm -v god
removed ‘god’

No FreeBSD, você não pode usar gmirrorem uma partição já montada, mesmo como root:

rótulo gmirror -v -b prefere gm0s1 ad4s1
gmirror: Não é possível armazenar metadados no ad4s1: operação não permitida.

Você precisa definir um sysctl( kern.geom.debugflags=16) para poder fazer isso.

rooté um usuário privilegiado, mas esses direitos são concedidos pelo kernel. Portanto, o kernel tem mais privilégios do que root.

Supondo que a colaboração do próprio usuário root rootpossa ser impedida de acessar montagens do FUSE (com as opções allow_otherou allow_root), mas isso ocorre porque o FUSE foi projetado para agir dessa maneira. Como o FUSE reside em uma camada virtual, ele pode retornar qualquer erro que desejar com base na lógica, em oposição aos módulos comuns de dispositivos de bloco que se esforçam para ser o mais transparente e fino possível, delegando permissões para outra camada.

Isso não impede que o usuário root desative a opção ou substitua o módulo FUSE por um que descarte silenciosamente a opção, a menos que você torne o sistema de arquivos somente leitura. No entanto, isso só leva a uma situação "quem vigia os vigias": como você pode validar que o sistema não está mentindo? Seu shell pode até estar em um chroot que mostra um módulo legítimo do FUSE, enquanto o kernel está realmente executando uma versão malévola dele.

Eu diria que a incapacidade de executar arquivos não executáveis ​​é trivialmente uma limitação, pois depende das permissões do arquivo. (É possível contornar isso usando /lib64/ld-linux-x86-64.so.2 em um arquivo não executável, mas não em uma montagem sem execução)

Há também a questão dos bloqueios obrigatórios de arquivos, que impedem a edição de arquivos se um arquivo estiver sendo usado no momento por um processo, embora o super usuário possa interromper o processo.

A certa altura, o superusuário não pôde desmontar um dispositivo enquanto o dispositivo estava ocupado, mas agora isso pode ser feito usando um montante lento.

Outras limitações são:

não pode modificar arquivos imutáveis ​​e só pode ser anexado a arquivos somente de acréscimo (o linux permite ao super usuário remover os sinalizadores imutáveis ​​e anexar apenas em qualquer nível de execução, no entanto, derrotando parcialmente o objetivo deles)

não pode gravar em uma montagem somente leitura ou executar qualquer coisa em uma montagem sem execução

não pode vincular uma montagem desmontável

Não é possível remontar um sistema de arquivos como leitura e gravação se seu dispositivo de bloco for somente leitura

não pode declarar nada em uma montagem de fusível de propriedade de outro usuário, a menos que seja montada allow-other ou allow-root

não pode violar as configurações do SELinux

limitações deliberadas inerentes ao próprio sistema, que afetam a raiz:

não é possível definir diretamente o horário c de um arquivo (ou o horário de nascimento, se ele já foi implementado)

não pode exibir senhas como texto sem formatação