Por que o Ubuntu tem uma conta root desativada?

O Ubuntu desabilita o login root por "razões de segurança". No entanto, parece-me que isso não ajuda em nada na segurança.

Se um invasor conseguir obter sua senha de login para o Ubuntu, ele também terá a senha de superusuário, pois é a mesma senha de login.

No entanto, se a senha de root for necessária, apenas o login não ajudará muito o invasor - é isso mesmo, não é?

Então, basicamente, o que eu quero saber é: Por que o Ubuntu optou por desativar a senha root? Quais são os motivos de segurança?

Por favor, não responda de acordo com o que você "acha" que foi o motivo - estou procurando uma resposta de fontes oficiais ou vinculada a elas.

Mitch postou um bom link no comentário: Por que é ruim fazer login como root? e o site Debian tem os principais benefícios listados em seu wiki :

Por que sudo?

Usar sudoé melhor (mais seguro) do que abrir uma sessão como raiz por vários motivos, incluindo:

• Ninguém precisa saber a senha root ( sudosolicita a senha do usuário atual). Privilégios extras podem ser concedidos a usuários individuais temporariamente e retirados sem a necessidade de alteração de senha.

• É fácil executar apenas os comandos que exigem privilégios especiais via sudo; o resto do tempo, você trabalha como um usuário sem privilégios, o que reduz os danos que os erros podem causar.

• Auditoria / registro: quando um sudocomando é executado, o nome de usuário original e o comando são registrados.

Pelas razões acima, mudar para o root usando sudo -i(ou sudo su) geralmente é preterido, porque cancela os recursos acima.

Em relação ao Ubuntu Os benefícios e as desvantagens estão listados em nosso wiki :

Benefícios do uso do sudo

Existem vários benefícios para o Ubuntu deixar os logins raiz desativados por padrão, incluindo:

• O instalador tem menos perguntas a fazer. Os usuários não precisam se lembrar de uma senha extra para uso ocasional (ou seja, a senha root). Se o fizessem, provavelmente esquecê-lo-iam (ou gravá-lo de maneira insegura, permitindo que qualquer um invadisse facilmente seu sistema).

• Evita o login interativo "Eu posso fazer qualquer coisa" por padrão. Você será solicitado a fornecer uma senha antes que ocorram alterações importantes, o que deve fazer você pensar nas consequências do que está fazendo.

• O sudo adiciona uma entrada de log do (s) comando (s) run (in /var/log/auth.log). Se você errar, você pode voltar e ver quais comandos foram executados.

• Em um servidor, todo cracker que tentar entrar com força bruta saberá que possui uma conta chamada root e tentará isso primeiro. O que eles não sabem é quais são os nomes de usuários de seus outros usuários. Como a senha da conta root está bloqueada, esse ataque se torna essencialmente sem sentido, já que não há senha para quebrar ou adivinhar.

• Permite a transferência fácil de direitos de administrador adicionando e removendo usuários de grupos. Quando você usa uma única senha root, a única maneira de desautorizar os usuários é alterando a senha root.

• O sudo pode ser configurado com uma política de segurança muito mais refinada. A senha da conta raiz não precisa ser compartilhada com todos que precisam executar algum tipo de tarefa administrativa no sistema (consulte o marcador anterior).

• A autenticação expira automaticamente após um curto período de tempo (que pode ser definido como o mínimo desejado ou 0); portanto, se você se afastar do terminal após executar comandos como root usando o sudo, não deixará um terminal raiz aberto indefinidamente.

Desvantagens do uso do sudo

Embora para os desktops os benefícios do uso do sudo sejam ótimos, existem possíveis problemas que precisam ser observados:

• Redirecionar a saída dos comandos executados com o sudo requer uma abordagem diferente. Por exemplo, considere sudo ls > /root/somefile não funcionará, pois é o shell que tenta gravar nesse arquivo. Você pode usar ls | sudo tee -a /root/somefilepara acrescentar ou ls | sudo tee /root/somefilesubstituir conteúdo. Você também pode passar o comando inteiro para um processo de shell executado no sudo para que o arquivo seja gravado com permissões de root, como sudo sh -c "ls > /root/somefile".

• Em muitos ambientes de escritório, o único usuário local em um sistema é raiz. Todos os outros usuários são importados usando técnicas NSS, como nss-ldap. Para configurar uma estação de trabalho ou corrigi-la, no caso de uma falha de rede em que o nss-ldap está quebrado, é necessário fazer root. Isso tende a deixar o sistema inutilizável, a menos que esteja quebrado. Um usuário local extra ou uma senha root ativada é necessária aqui. A conta de usuário local deve ter seu $ HOME em um disco local, nãono NFS (ou qualquer outro sistema de arquivos em rede) e um .profile / .bashrc que não faça referência a nenhum arquivo nas montagens do NFS. Geralmente, esse é o caso do root, mas se você adicionar uma conta de resgate não raiz, será necessário tomar essas precauções manualmente. No entanto, a vantagem de usar um usuário local com o sudo é que os comandos podem ser facilmente rastreados, conforme mencionado nos benefícios acima.

E sempre tivemos isso (desde o primeiro lançamento).

A referência mais antiga que encontrei fala da 4.10 que possui "sudo"

SHUTTLEWORTH LANÇA UBUNTU LINUX BASEADO EM DEBIAN

... O Ubuntu Linux baseado no Debian inclui o Gnome 2.8, kernel 2.6.8.1, OpenOffice.org 1.1.2 e vem com um procedimento de instalação baseado em texto, mas fácil. O Ubuntu desativou o usuário root, preferindo usar o sudo da mesma forma que o Mac OSX ...

Acredito que o que está escrito na página de ajuda seja suficientemente claro e objetivo.

O Ubuntu é "para todos" e, se você é bom o suficiente, não precisa de acesso root para danificar seu computador, mas ao mesmo tempo não precisa dele (e sabe como habilitá-lo facilmente).
Portanto, o problema não é com pessoas que são "boas o suficiente", mas para todos os outros, que podem chegar ao Linux de outro mundo da computação e o primeiro impacto é no Ubuntu (e somos muitos).

Se você não é um especialista e não sabe exatamente o que rooté e como lidar com isso adequadamente, não deseja nem precisa habilitá-lo (e arrisca, por exemplo, fazer um login gráfico com ele).
É muito melhor aprender a fazer as coisas do lado seguro e seguir para o caminho mais difícil e perigoso, do que começar diretamente pelo caminho mais difícil e danificar sua instalação / estação de trabalho, ficar frustrado e talvez não conseguir recuperar um ambiente totalmente funcional. sistema.
Em geral, prevenir é muito melhor do que remediar.