De que maneiras existem para restringir severamente e permanentemente o acesso a privilégios de superusuário no Linux? [fechadas]

Question

Então, eu queria saber se é possível criar um sistema Linux sem qualquer (ou próximo a qualquer) processo de espaço do usuário rodando como superusuário / root, e sem (ou próximo a nenhum) maneiras de outros processos aumentarem seus privilégios? / p>

Quais são as soluções técnicas que poderiam ser usadas para implementar isso? Quais seriam as armadilhas técnicas nisso?

    

Answer 1

Embora não seja prático remover o superusuário, é possível limitar o acesso que o usuário root tem no interesse de segurança.

link

Vou incluir alguns trechos, mas copiá-los todos seria uma grande resposta, então vou apenas dar a essência:

The following are four different ways that an administrator can further ensure that root logins are disallowed:

Changing the root shell

To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin in the /etc/passwd file.

Disabling root access using any console device (tty)

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether through the console or a raw network interface. This is dangerous, because a user can log in to their machine as root using Telnet, which transmits the password in plain text over the network.

Disabling root SSH logins

To prevent root logins through the SSH protocol, edit the SSH daemon's configuration file, /etc/ssh/sshd_config, and change the line that reads:

#PermitRootLogin yes

to read as follows:

PermitRootLogin no

Using PAM to limit root access to services

PAM, through the /lib/security/pam_listfile.so module, allows great flexibility in denying specific accounts. The administrator can use this module to reference a list of users who are not allowed to log in. To limit root access to a system service, edit the file for the target service in the /etc/pam.d/ directory and make sure the pam_listfile.so module is required for authentication.

Todas as seções têm mais informações que eu deixei de fora, mas podem colocá-lo em outras leituras caso seja do seu interesse.

SELINUX

selinux pode ser usado para remover root privileges em geral, modificando o contexto selinux do serviço / executable / port / etc. Isso está entrando em um tópico enorme, então eu vou ligar o documento do RHEL ao invés de entrar em um monte: link

Para uma restrição de exemplo realmente brutal, execute selinux em enforcing e tente: semanage login -a -s user_u root .

Isso distribuiria as permissões de usuário padrão para o usuário root (supondo que ele seja executado, não tenho certeza, já que não tenho uma máquina a ser bloqueada no momento) e restringi-lo de fazer qualquer "root" "como ações.

Isso, no entanto, pode impedir que init e vários serviços sejam iniciados, portanto, pode exigir muita outra configuração selinux para permitir que esses serviços sejam executados como algum outro usuário (que pode ser insanamente seguro e insanamente difícil de manter, dado que comprometer um serviço não daria acesso a outros).

    

Answer 2

Uma distro que não oferecia capacidade de superusuário seria praticamente inutilizável, uma vez que não permitiria que o usuário, por design, executasse qualquer configuração de sistema, instalação de driver ou atualização.

É como o famoso "computador perfeitamente seguro", que é uma máquina desconectada e desligada.
Este é um exemplo da balança "segurança / usabilidade" levada ao extremo (para segurança máxima e baixa usabilidade).

Além disso, o kernel ainda executa operações de privilégios acima do usuário na inicialização, e essas (como qualquer operação) ainda são hackíveis.

    

Answer 3

Centimane deu uma resposta muito completa . Aqui estão alguns pensamentos adicionais:

• Você pode querer remover cron , porque precisa ter o privilégio de definir o UID de um processo para qualquer valor.
• Qualquer processo que precise ler qualquer arquivo pode ser executado como um usuário não-root com o recurso “CAP_DAC_READ_SEARCH” - veja this , esta , e this .
• Processos que precisam ser capazes de gravar em arquivos de "sistema" pode ser dado UIDs não-raiz (talvez um diferente para cada programa, ou para cada recurso) e, em seguida, receber acesso às ACLs.
• Processos que precisam ser capazes de fazer coisas "privilegiadas" pode ser capaz de fazer isso com outros recursos (discutidos acima); veja Princípio do menor privilégio .

Para fazer alterações de configuração após a configuração e contornar as restrições root :

• Configure o computador para inicialização dupla.
• Um sistema operacional seria o endurecido, com acesso e atividade root mínimos.
• O outro seria um Linux mais ou menos normal, mas com os drivers de rede removidos.
• Na ocasião (rara?) do administrador do sistema precisando administrar o sistema, eles poderiam desligar, inicializar no Linux normal, faça o que precisa ser feito e reinicie.

Aparentemente, SELinux e AppArmor explicitamente suportam esta noção .