Ouvi muitas vezes que é melhor su para fazer root do que fazer login diretamente como usuário root (e é claro que as pessoas também dizem que é ainda melhor usar o sudo). Eu realmente nunca entendi por que um é melhor que o outro, insight?
Respostas:
A inferência é somente suou sudoquando necessário.
A maioria das tarefas diárias não requer um shell raiz. Portanto, é uma boa prática usar um shell sem privilégios como comportamento padrão e, em seguida, elevar para o root apenas quando você precisar executar tarefas especiais.
Ao fazer isso, você reduz o escopo de erros perigosos (scripts incorretos, curingas extraviados etc.) e vulnerabilidades de todos os aplicativos que você usa. Especialmente aqueles que se conectam à Internet - veja o velho ditado "Não IRC como root" .
sudo é frequentemente recomendado porque permite uma granulação fina e audita o uso desses privilégios.
Ao observar essas práticas, você também poderá desativar os logins raiz remotos. Isso aumenta a barra de entrada para qualquer possível invasor, pois eles precisam comprometer uma conta de usuário comum que fosse membro do grupo "wheel" e, idealmente, autorizada apenas pelas chaves públicas SSH, e depois pela própria conta root.
sudoseja superior, sutambém permite que você use o -msinalizador para manter as variáveis de ambiente iguais em um terminal raiz. Nada me deixa mais maluco do suque torcer um pouco, apenas para fazer algo com ~o nome do diretório e fazê-lo não funcionar.
O principal motivo é criar uma trilha de auditoria. Se você precisar fazer login em um sistema como um usuário comum e depois su, é possível rastrear quem é responsável por determinadas ações.
O sudo também registra automaticamente todos os comandos no syslog e você pode definir os comandos que cada usuário pode usar.
sudo vim foo.txtlargar para um shell no vim fornecerá um shell raiz sem o registro regular do sudo.
sudo -ipara obter uma sessão interativa ...
Se você deseja criar uma trilha de auditoria e não deseja ser vítima dos problemas "sudo su -" ou "sudo vim foo.txt" mencionados aqui, você pode usar "sudosh". Distribua o acesso root via sudo, mas faça o único comando permitido para executar "sudosh".
sudosh é um shell de registro e você pode reproduzir toda a sessão do terminal posteriormente, mostrando exatamente o que o usuário viu no terminal.
Você deve praticar a segurança em profundidade.
Proibir o acesso root remoto (ou pelo menos o acesso root através de senhas). (se você permitir acesso root via chaves, controle-as com cuidado ou, melhor ainda, use algo como o kerberos que permita a revogação centralizada de chaves).
Eu desativaria o su e usaria o sudo. Dessa forma, os usuários usam chaves (de preferência criptografadas) para acessar o sistema e, em seguida, usam suas senhas apenas para escalar privilégios. Você pode restringir os programas que as pessoas acessam com o sudo, mas principalmente restringe o acesso a quem sabe a senha root.
Em um mundo ideal, você deve poder publicar suas senhas de root na Internet e isso não importaria, mesmo que você desse acesso às pessoas à sua máquina (mas não as colocasse no arquivo / etc / sudoers). Obviamente, você não deve publicar a senha root, mas a idéia é que você proteja seus sistemas com camadas concêntricas de proteção.
Se você estiver usando o root regularmente, suas permissões podem estar erradas ou pode ser necessário conceder direitos sudo ou um novo grupo para r / w / x os arquivos ou diretórios.
Os bons esquemas de permissões são algo que até os usuários antigos do Linux erram ou não percebem o escopo que possuem.
Nem me inicie no que o Ubuntu fez!