Como funciona a detecção de sudo / root? ness

Question

Programas que fazem alterações em todo o sistema exigem sudo a menos que eu já seja o usuário root .

Agora, a questão é: como exatamente o sistema descobre que eu sou (não) raiz?

Isso:

• Verifique se estou em um grupo específico? Se sim, em qual grupo eu preciso estar?

• Verifique um ID conhecido da própria raiz (por exemplo, "o usuário root" é codificado na origem)?
  Em caso afirmativo, o que acontece se minha conta raiz for corrompida? Eu seria forçado a reinstalar o sistema operacional, já que não há como criar outra conta com privilégios de root?

• Verifique meu nome / grupo contra o conteúdo de algum arquivo e conceda o privilégio certo? Em caso afirmativo, qual arquivo contém essas informações?

• Fazer outra coisa? Se sim, o que isso faz?

Answer 1

Os nomes de usuários no Unix não são significativos. Somente IDs de usuário numéricos são. O ID numérico da raiz é sempre 0. Isso é codificado em todo o lugar (no kernel, nos utilitários, etc.).

Você pode encontrar seu ID de usuário numérico executando id .

Observe que seu ID de usuário numérico é uma propriedade do processo em execução. Quando você faz o login, o processo no qual você faz login ( login , sshd , etc.) é executado como root (UID 0) e, assim que seu login é autorizado, ele alterna para seu ID de usuário e executa seu shell (especificado em / etc / passwd). A partir daí, para usar sudo , su ou qualquer outra coisa para trocar IDs de usuário, esses programas têm o bit setuid definido ( chmod u+s ou chmod 4xxx definirá isso), para que quando eles são executados, o processo é executado como o proprietário do programa (raiz, UID 0). Novamente, uma vez que você esteja autorizado, eles executam qualquer programa (seja o que for que você disser sudo para executar, um shell, etc.) como root. (No caso de su , se você especificar outro usuário para alternar, ele será transferido para esse UID e, em seguida, executará o shell ou qualquer outra coisa.)

Para responder à sua outra pergunta, não há como a conta root "ficar corrompida", já que ela é apenas um número, mas pode haver razões pelas quais você não pode simplesmente fazer o login root (como esquecer a senha, por exemplo). Nenhum deles deve exigir a reinstalação do sistema operacional, mas eles podem exigir um pouco de habilidade técnica para corrigir. (Por exemplo, se você esquecer a senha do root, poderá usar o sudo para obter root usando sua senha, inicializar no modo de usuário único para redefinir a senha ou inicializar a partir da mídia ao vivo ou de um ambiente de recuperação.)

    

Answer 2

Em 25 anos lidando com o Unix, nunca vi um caso em que a conta root fosse corrompida sem que o próprio sistema fosse utilizável. As senhas esquecidas podem ser facilmente redefinidas, e não vejo isso como corrupção. Houve um incidente memorável em um Vax rodando o BSD onde eu acidentalmente (não perguntei) removi tudo do / dev, incluindo as entradas para a unidade de fita (fitas de bobina de 1/4 "). Isso torna um pouco difícil de restaurar de backup.

No Unix, não há realmente nada para corromper. O processo de login apenas inicia um shell e executa os arquivos rc a partir do diretório inicial do root. Com exceção dos arquivos rc, se o resto não funcionar para o root, provavelmente não funcionará para mais ninguém. Se você está logando como root em um sistema gráfico (KDE ou Gnome), tudo que posso dizer é "Apenas não".

Você pode ter várias contas, todas com uid 0. Isso pode ser usado como uma alternativa ao sudo quando houver vários administradores para uma máquina. A desvantagem é que agora você tem várias contas raiz para proteger. Você também não recebe o registro que o sudo faz por você.

    

Answer 3

A resposta de Steven Pritchard é bom, mas eu pensei em oferecer uma apresentação diferente de informações similares.

Cada processo é executado como um determinado usuário¹. O usuário é identificado por um número, o ID do usuário, que é armazenado nas informações de processo disponíveis apenas para o kernel. O usuário cujo ID do usuário é 0 possui privilégios especiais e é normalmente chamado de root ; o nome root não é especial para o kernel (mas, se você alterá-lo, provavelmente confundirá muitos aplicativos). Muitas coisas, como carregar módulos do kernel, acessar a maioria dos dispositivos de hardware diretamente e assim por diante, exigem que o processo que executa a ação seja executado como ID do usuário 0².

Quando o sistema inicializa, o primeiro processo iniciado pelo kernel é executado como o superusuário. Esse processo, chamado init , inicia um número de serviços do sistema ( cron , syslogd ,…) e programas de login ( login , sshd , etc.).

Ao efetuar login, você insere as credenciais (nome, senha,…) e o programa de login as verifica. Se as credenciais forem aceitas, o programa de login será alterado para seu ID de usuário (esse é um dos privilégios concedidos ao superusuário).

Se você estragar o banco de dados do usuário (o que é improvável se você não sair editando ou removendo arquivos aleatórios como root), talvez não consiga mais fazer login. Você ainda poderá inicializar no modo de usuário único ou em um CD ao vivo para reparar seu sistema.

O programa sudo permite que você execute comandos como root. Normalmente, se você executar um programa, ele herdará o ID do usuário do processo que o iniciou. Mas sudo é setuid root: essa é uma exceção, determinada pelos bits de permissão em /usr/bin/sudo , que fazem isso executar como ID de usuário 0 em vez disso. sudo verifica se o usuário que o invocou tem permissão para executar um comando com privilégios elevados (consultando /etc/sudoers ) e executa o comando ou sinaliza um erro.

¹ _{Às vezes, mais de um, mas isso não aparece nesta resposta.}
² _{Ou tenha o recurso correto , mas não importa isso por enquanto.}

    

Answer 4

Portanto, as respostas anteriores de Steven Pritchard e KeithB estão corretas, mas há algumas sutilezas a serem observadas sobre como o ID do processo é realmente gerenciado.

Como mencionado, o nome de usuário é totalmente irrelevante para o kernel ou qualquer gerenciamento de processo, e é mapeado apenas no espaço do usuário com base nos mecanismos / etc / passwd ou similares, então esqueça tudo sobre isso. O Root é de fato codificado, e é uid 0 por definição em qualquer sistema POSIX (ou qualquer coisa, mesmo remotamente UNIXy, até onde eu saiba).

As permissões são calculadas com base nas propriedades do processo atualmente em execução . Há o real uid , que é o uid do usuário que iniciou o processo, e o uid eficaz , que é o uid que o processo é tratado para fins de permissões. Quando você executa coisas do shell, o shell é o processo pai - e os processos filhos sempre herdam o fluxo real do pai, que é seu uid se você estiver executando em um shell de login. Processos para os quais setuid está habilitado podem mudar seu uid efetivo (mas nunca seu uid real ou salvo) - processos rodando com uid efetivo de 0 (como root) podem mudar para qualquer outro uid, e outros processos só podem alterar o euid entre o uid uid real e salvo - outra propriedade de processo que é sempre o euid original do processo (equivalentemente, o uid efetivo do pai no ponto em que exec() foi chamado). Isso não pode ser alterado por usuários sem privilégios e o root pode alterá-lo apenas para o uid real.

Todos esses também são relevantes para permissões de grupo, apenas s / uid / gid.

Como um aparte, geralmente considero o sudo menos útil do que ativar o su e gerenciar adequadamente o grupo wheel.

    

Answer 5

O conceito de privilégio "root" é distribuído em vários mecanismos de controle:

1. Hardware: CPU Intel (e todas as outras CPUs em geral) têm vários "estados privilegiados" - e em cada um desses estados privilegiados você pode ou não executar certas classes de instruções de montagem - geralmente o estado mais privilegiado terá o poder de executar mais instruções.

link

link

E uma das instruções privilegiadas é controlar a tabela de páginas de memória. E esses vários toques também oferecem threads de execução do kernel versus espaço do usuário.

2. De (1), passando pelo mecanismo de tabela de páginas, você também terá vários tipos de memória: anel 0 ou anel 3 de memória.

link

link

O anel 0 terá mais privilégios e armazenará todas as suas informações confidenciais - entre elas estão as informações do USERID. Se você é userid = 0, você é privilegiado, e se não, então apenas um usuário normal. E cada usuário tem tabelas de páginas diferentes no kernel - é por isso que cada processo não pode modificar a memória diretamente. E lembre-se que o userid é armazenado na memória do ring0 - seus processos rodando no ring 3 nunca poderão modificar esta informação, e se você puder, então você deve ter escalado para o kernel para modificá-lo ("escalada de privilégios").

Para verificar se você é root ou não-root - faça isso no kernel:

  if (current_cred()->uid != 0)
     return -EPERM;

E se você não está no kernel - você não tem acesso a todas as credenciais armazenadas no kernel. E um processo não pode ler outra memória de processo - então nenhuma verificação é necessária se você não estiver no kernel, o que pode ver TODA a memória para todo o processo.

Para resumir: qualquer processo que você esteja executando, que está sempre rodando no privilégio ring 3 (para Intel), terá informações de userid mantidas no kernel - que devem ter sido originalmente criadas a partir de outro componente do kernel , ou um processo raiz (userid = 0). Qualquer processo de propriedade da raiz (que ainda está sendo executado no ring3) terá recursos (por que? Porque está escrito dentro do próprio código-fonte do kernel do Linux:

link ) para fazer a transição para o privilégio ring 0 facilmente . Isso explica por que não importa como você modifica sua própria memória (que está rodando no ring 3) você nunca poderá ver / mudar seu userid.

E você perguntou se a propriedade era armazenada em arquivos. Os arquivos yes contêm propriedade de ID do usuário. E um processo em execução (com um ID de usuário específico) não pode modificar outros arquivos com um ID de usuário diferente. A segurança é compartimentada desta forma em arquivos + processos em execução (onde o ID do usuário é armazenado na memória do kernel). Mas você não pode ter certeza de que alguém não pode ler seus arquivos físicos.

Se você pode levar o disco rígido para outra máquina que você tem controle de raiz, você pode assumir como qualquer ID de usuário necessária para ler os arquivos físicos de propriedade do usuário no disco rígido. ou seja, se você não tiver segurança física, poderá ignorar todo o mecanismo de segurança no disco rígido, a menos que esteja criptografado.