Quais direitos de acesso não podem ser violados pelo superusuário?

Question

Fr. 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, há algum direito de acesso que pode proibir o superusuário de fazer algo.

Não consegui encontrar esta informação na Internet e estou curioso para saber o que são. Isso é provavelmente algo relacionado à execução do núcleo do sistema, não é? Talvez ele não possa parar alguns processos do sistema? Ou talvez ele não consiga executar um processo em modo real?

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

    

Answer 1

acess denied to root :

root pode ser negado acesso direto à rede. Isso é útil em hosts conectados à Internet, pois exige o login como smith e, em seguida, sudo .

algumas coisas que o root não consegue fazer :

Isto NÃO é por falta de privilégio. Não consigo ver nada que a raiz não possa fazer, no entanto, alguns problemas técnicos podem ser sentidos como "proibidos".

I am root, why can't I create/delete this file, while ordinary user can?

Você está em um compartilhamento NFS / samba e não deu autorização específica ( access= ). Usuário comum falha em lei comum. (veja root local vs remote abaixo)

I am root, why can't I kill this process?

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

I am root, how do I get archemar's password?

Você pode su - archemar , ou alterar a senha do archemar sem saber o anterior, mas não pode lê-lo (com exceção de um registrador de chaves), já que as senhas são armazenadas usando um hash unidirecional.

raiz local vs remota

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

Agora

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

simplesmente faça o login no servidor NFS, execute ./bash e você é root no servidor da empresa / universidade.

    

Answer 2

No caso usual, isso é incorreto - o superusuário tem privilégios / permissões para qualquer funcionalidade que o sistema forneça (1). Onde esta regra quebra é quando você joga o SELinux na mistura. Com o SELinux, é possível restringir até mesmo privilégios de root para proibir 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 questão não pode ser respondida no sentido geral.

(1) - se um sistema não fornece um dado recurso, por exemplo não há funcionalidade de kernel em tempo real, então eu estou considerando que a afirmação "root não tem acesso a esta funcionalidade" seja falsa, já que essa afirmação depende de uma suposição falsa (a saber, que o recurso dado está disponível para qualquer pessoa nesse sistema) )

    

Answer 3

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

• diretórios de hard-linking (por causa das limitações do sistema de arquivos)
• escrevendo para um CD-ROM já gravado (por causa da física)

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

Depois, há 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 que o código seja executado apenas se tiver sido assinado pela Apple.

Eu 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.

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

Além desses casos, quase nada de raiz pode fazer.
Há, no entanto, uma coisa chamada modo kernel (em oposição ao modo de usuário).

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

Existem sistemas, no entanto, (como o iOS), onde isso não é (arbitrariamente) possível, pelo menos não sem explorar os conjuntos de segurança. Isso ocorre principalmente devido 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 só podem ser acessadas no modo kernel. Os módulos do kernel poderiam acessá-los, mas o código nesses módulos do kernel também teria que ser assinado pela Apple para que o kernel os aceitasse.

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

Here's what it restricts, even from root:

• You can't modify anything in /System, /bin, /sbin, or /usr (except /usr/local); or any of the built-in apps and utilities. Only Installer and software update can modify these areas, and even they only do it when installing Apple-signed packages.

    

Answer 4

A "execução do núcleo do sistema" que você está mencionando está bem abaixo do controle de root , por exemplo, via módulos carregáveis do kernel. Claro, isso pressupõe que carregar módulos do kernel é suportado pelo kernel, ninguém pode realizar ações que não são viáveis, mesmo root .

O mesmo é verdadeiro para processos do sistema. root tem 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 esse processamento imediatamente. Note que root não será negado para matar esses processos, mas matar-se simplesmente não terá efeito.

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

@Siguza mencionou a execução de arquivos sem a permissão x , o que é bem possível para o usuário root :

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

    

Answer 5

Um exemplo pode ser a modificação do arquivo imutável: você pode definir um atributo de arquivo i com chattr , o que torna o arquivo imutável 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 um arquivo gravável normal em ls -l output:

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

Para ver o atributo i , você precisa usar lsattr :

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

A página de manual do chattr indica a seguir sobre o atributo i :

A file with the 'i' attribute cannot be modified: it cannot be deleted or renamed, no link can be created to this file and no data can be written to the file. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

No entanto, o root pode facilmente desfazer a imutabilidade:

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

    

Answer 6

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

gmirror label -v -b prefer gm0s1 ad4s1
gmirror: Can't store metadata on ad4s1: Operation not permitted.

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

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

    

Answer 7

Assumindo a colaboração do próprio usuário raiz, root pode ser impedido de acessar montagens do FUSE (com as opções allow_other ou 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, ao contrário dos 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 a opção silenciosamente, a menos que você torne o sistema de arquivos somente leitura. No entanto, isso só leva a uma situação de "quem observa 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 FUSE legítimo, enquanto o kernel está executando uma versão malevolente dele.

    

Answer 8

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 para um arquivo não-executável, mas não um arquivo em uma montagem no-exec)

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 por um processo, embora o superusuário possa eliminar o processo.

Em um ponto, o superusuário não pôde desmontar um dispositivo enquanto o dispositivo estava ocupado, mas isso agora pode ser feito usando um retardo lento.

Outras limitações são:

não pode modificar arquivos imutáveis, e pode apenas anexar arquivos somente de anexação (o linux permite que o super usuário remova os sinalizadores imutáveis e anexar somente em qualquer nível de execução, no entanto, parcialmente derrotando o propósito deles)

não pode gravar em uma montagem somente leitura ou executar qualquer coisa em uma montagem sem-exec

não pode ligar uma montagem não conectável

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

não pode declarar nada em uma montagem de fusível pertencente a outro usuário, a menos que esteja montado 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 pode definir diretamente a hora c de um arquivo (ou a hora de nascimento, se já foi implementada)

não pode visualizar senhas como texto simples