Por que é ruim fazer login como root?


192

Eu sempre me deparei com posts em fóruns ou outros sites em que você vê pessoas brincando de maneira a executar / fazer login como root, como se isso fosse algo horrível e todos deveriam saber sobre isso. No entanto, não há muito que uma pesquisa revele sobre o assunto.

Pode ser amplamente conhecido pelos especialistas em Linux, mas eu realmente não sei por quê. Lembro-me de sempre ter rodado como root quando tentei o Linux anos atrás (Redhat e Mandrake) e não me lembro de ter problemas por causa disso.

Na verdade, existem algumas distros que têm um fundo vermelho brilhante com sinais de alerta por todo o lado como papel de parede para o usuário root (SuSe?). Ainda uso a conta "Administrador" para uso regular na minha instalação do Windows e também nunca tive problemas.


15
Eu acho que não há problema em executar um programa como root. É só isso, você pode prejudicar o núcleo do seu sistema operacional (até sudoers podem fazer isso) se você não for muito sábio no Linux. Fora isso, eu não acho que há algum problema. Mas esse é apenas o meu ponto de vista.
Gaurav Butola

1
Pergunta relacionada aqui .
Loevborg

A dificuldade de entrar no modo raiz varia entre as distribuições. Pessoalmente, estou irritado com a forma como o Fedora não permite que você 'sudo' saia da caixa. O OpenSUSE e o Ubunto possuem sudo pré-configurado ... e, portanto, se você escolher a distribuição certa, poderá minimizar seus aborrecimentos por não conseguir acessar os arquivos.
djangofan

4
@GauravButola, mesmo que você seja um especialista, ainda é uma má ideia caso um aplicativo seja comprometido.
strugee

2
@DaboRoss o OP comenta que ele trabalha no Windows como administrador; para minha (pouca) experiência nesse sistema operacional, parece-me que é mais parecido com o Ubuntu: é uma conta privilegiada no sentido de poder fazer o que você quiser, mas pede permissão antes, por exemplo, para instalar um novo software. Portanto, provavelmente o equivalente a usar o usuário "administrador" no Windows traduzido para o Ubuntu seria executar o usuário principal com o sudo configurado para que ele não solicite a passagem - rodar diretamente, pois o root é muito mais perigoso.
Rmano 21/01

Respostas:


154

Ele derrota o modelo de segurança que existe há anos. Os aplicativos devem ser executados com segurança não administrativa (ou como meros mortais), para que você precise elevar seus privilégios para modificar o sistema subjacente. Por exemplo, você não gostaria que aquela falha recente do Rhythmbox acabasse com todo o /usrdiretório devido a um bug. Ou a vulnerabilidade recém-lançada no ProFTPD para permitir que um invasor obtenha um shell ROOT.

É apenas uma boa prática em qualquer sistema operacional executar seus aplicativos no nível do usuário e deixar tarefas administrativas para o usuário raiz, e apenas conforme a necessidade.


5
... e protege você de transformar erros triviais em desastres. Eu sou um Unix usuário / adm desde 1990, mas ainda assim eu certamente pode escorregar um espaço no exato lugar errado fazendo um rm -rf tmp/tests/*...
Rmano

9
1.) A maioria das pessoas considerará seu diretório pessoal mais importante que os diretórios raiz, pois o primeiro não pode ser reinstalado. Então, eu não entendo o seu ponto. 2.) Em termos de segurança, você está certo. Mas vindo do Windows (onde há MUITO MAIS malware), onde eu usei a conta de administrador desde sempre (como muitos fazem), tenho dificuldade em considerar isso um perigo real. Estou com preguiça de digitar sudoe minha senha para cada segundo comando no Linux. Os usuários do Linux não deveriam ser preguiçosos ?????
phil294

discordo -_-: ~: |
precisa saber é o seguinte

@ LazyPower, obrigado por editar sua resposta, mas agora não a entendo mais. Para modificar minha pasta privada do Ubuntu ~, os programas não precisam de direitos sudo. O Rhythmbox PODE apagar todo o meu diretório $ HOME / Music! E é isso que me interessa! Como isso está relacionado às permissões de root?
phil294

1
Essa é uma boa chamada para @Blauhirn. Acabei de enviar uma edição de acompanhamento para refletir que não queremos que ela exclua a totalidade de / usr. Em termos de proteção de suas pastas $ HOME, nada como um bom backup pode ajudá-lo. Eu não acho que esse cenário específico esteja relacionado à segurança, tanto quanto às boas práticas. Mais uma vez obrigado pela frase de destaque.
usar o seguinte código

79

Apenas uma palavra: segurança.

  1. Você está logado como root = todos os aplicativos em execução com privilégios de root - todas as vulnerabilidades no Firefox, Flash, OpenOffice etc. agora podem destruir seu sistema, porque possíveis vírus agora têm acesso a todos os lugares. Sim, existem apenas alguns vírus para Ubuntu / Linux, mas também por causa da boa segurança e do usuário não privilegiado padrão.
  2. Não se trata apenas de vírus - um pequeno bug em um aplicativo pode apagar alguns arquivos do sistema ou ...
  3. Quando você está logado como root, pode fazer tudo - o sistema não pergunta! Deseja formatar este disco? Ok, apenas um clique e pronto, porque você é o principal e sabe o que está fazendo ...

16
Os arquivos de dados, todos pertencentes à minha conta de usuário, são muito mais valiosos para mim do que os arquivos do sistema. Todos os exemplos acima ainda são problemas quando você faz login como usuário, exceto que os arquivos de sistema facilmente substituíveis são protegidos.
kbeta

5
@kbeta, você está assumindo que está executando em um computador em que os únicos objetos de valor são seus dados e arquivos do sistema. Na realidade, o linux é frequentemente usado em um sistema em que existem muitos usuários usando um sistema simultaneamente. Nesse caso, a estabilidade do sistema (e, portanto, os arquivos do sistema) é muito mais valiosa e outros arquivos do usuário também são importantes.
Eric Pauley 28/02

2
@kbeta É justo o suficiente, mas uma configuração do sistema danificada também pode representar um risco para os seus dados ... e, é claro, ter backups seria uma boa idéia se o seu sistema está em risco atualmente ou não. Trabalhar o backup atual com um plano de recuperação de desastre seria melhor ainda.
Pryftan

47

A execução como root é ruim porque:

  1. Estupidez: nada impede que você faça algo estúpido. Se você tentar alterar o sistema de qualquer maneira que possa ser prejudicial, precisará executar o sudo, que praticamente garante uma pausa enquanto você digita a senha para perceber que está prestes a fazer uma possível alteração grande / dispendiosa.
  2. Segurança: já foi mencionado várias vezes nesta pergunta, mas basicamente é a mesma coisa, mais difícil de invadir se você não souber a conta de login do usuário administrador. raiz significa que você já possui metade do conjunto de trabalho de credenciais de administrador.
  3. Você realmente não precisa disso: se você precisar executar vários comandos como root e ficar chateado por ter que digitar sua senha várias vezes quando o sudo expirar, tudo que você precisa fazer é sudo -ie agora você é root. Deseja executar alguns comandos usando pipes? Então use sudo sh -c "comand1 | command2".
  4. Você sempre pode usá-lo no console de recuperação: O console de recuperação permite que você tente se recuperar de fazer algo estúpido ou corrigir um problema causado por um aplicativo (que você ainda precisava executar como sudo :)) O Ubuntu não tem uma senha para a conta raiz, neste caso, mas você pode pesquisar on-line para alterar isso. Isso tornará mais difícil para qualquer pessoa que tenha acesso físico à sua caixa causar danos.

O motivo pelo qual você não conseguiu encontrar informações sobre o porquê é ruim é porque, bem, há muitos dados na internet :) e muitas pessoas que usam o Linux há muito tempo pensam como você. Essa maneira de pensar sobre a conta raiz é relativamente nova (talvez uma década?) E muitas pessoas ainda ficam irritadas por terem que usar o sudo. Especialmente se eles estiverem trabalhando em um servidor, o que significa que eles entraram com a intenção de fazer alterações no sistema. Provavelmente provocado por más experiências e padrões de segurança anteriores, a maioria dos administradores de sistemas conhece melhor, mas ainda não gosta :).


talvez uma década? Muito mais tempo do que isso, mesmo quando você escreveu isso. Mesmo sem o sudo, há su para não mencionar, por exemplo, o grupo de rodas (por exemplo). A separação de privilégios é sempre importante e sempre foi importante e sempre será importante. Otoh não como muitas pessoas usaram o SO baseado em Unix há muitos anos e muitos que costumam ser sempre administradores.
Pryftan

36

Essa é uma boa pergunta. Acho que a resposta é um pouco diferente, dependendo se você está falando de um servidor ou de uma instalação de desktop.

Em uma área de trabalho, é incomum usar a rootconta. De fato, o Ubuntu é fornecido com o acesso root desativado. Todas as alterações que requerem privilégios de superusuário são feitas sudoe seus conhecimentos gráficos gksudoe kdesudo. Como é fácil definir uma rootsenha, no entanto, por que as pessoas não fazem isso?

Um dos motivos é que ele oferece uma camada adicional de segurança. Se você executar um programa como roote uma falha de segurança for explorada, o invasor terá acesso a todos os dados e poderá controlar diretamente o hardware. Por exemplo, ele pode instalar um trojan ou key-logger no seu kernel. Na prática, porém, um ataque pode causar uma grande quantidade de dano, mesmo sem privilégios de superusuário. Afinal, todos os dados do usuário - incluindo documentos e senhas armazenadas - são acessíveis sem acesso root.

Um ponto mais válido, em um sistema de usuário único, é que o usuário é impedido de acidentalmente inutilizar o sistema. Se o usuário não intencionalmente emitir um comando que exclui todos os arquivos, ele ainda poderá inicializar o sistema, mesmo se os dados forem perdidos.

Além disso, a maioria dos aplicativos voltados para o usuário (X11) hoje é construída com base no pressuposto de que eles são executados como uma conta de usuário comum e sem direitos de administrador. Portanto, alguns programas podem se comportar mal quando executados como root.

Em um sistema multiusuário com acesso não gráfico ao shell, muitos desses motivos não se aplicam. No entanto, o Ubuntu ainda usa como padrão uma rootconta inacessível . Por um lado, há uma diferença real entre obter acesso a uma conta de usuário (com sudodireitos) por meio de uma brecha de segurança e obter acesso root, pois, no primeiro caso, interromper outros usuários exigirá execução sudoe ainda solicitará a senha da conta como um etapa de segurança adicional. Por outro lado, é útil executar muitas tarefas administrativas de uma conta de usuário e chamar apenas sudoquando os privilégios de superusuário são absolutamente necessários. Assim, ao instalar um programa a partir da fonte, é aconselhável criar a fonte - executando configureemake- dentro do diretório do usuário e usando apenas sudo make installna etapa final. Novamente, isso torna mais difícil disparar contra si mesmo (e outros usuários do sistema multiusuário) no pé, e diminui a probabilidade de scripts de criação causar estragos no sistema. Assim, mesmo em um servidor, é um bom conselho manter a administração baseada em sudo do Ubuntu .


2
he will still be able to boot the system, even if the data will be lost.- Qual o sentido disso? Se meus dados são perdidos, meus dados são perdidos e é isso. O software do sistema Linux pode ser reinstalado se excluído. Por que devo me preocupar com a perda de dados nesses diretórios? Por outro lado, a perda de dados ~é ruim. E sudonão me protege disso.
phil294

2
Outra boa prática é fazer backup de dados importantes. Se você apagar o diretório inicial, ainda poderá inicializar e copiar os arquivos do backup. Ou, digamos que você tenha um laptop pequeno para viajar. Pode ter algumas fotos, notas de viagem, horário de trem - mas nada muito crucial. Se você limpar os arquivos do usuário, ainda poderá inicializar o sistema e fazer o check-in do seu voo ou descobrir qual ônibus tomar.
Richlv

@Blauhirn Backups. E há uma chance de recuperação, mesmo que pareça sombrio.
Pryftan

34

Um motivo para não ser executado como raiz que ainda não foi identificado por outras respostas é a rastreabilidade. Provavelmente é menos importante em máquinas que são basicamente máquinas monousuário (desktop ou laptop), mas em máquinas servidoras, se alguém estiver logado como root, você não sabe a quem culpar pelas ações tomadas. Portanto, a maioria das organizações profissionais com vários sistemas e vários administradores que precisam de rootprivilégios exige que as pessoas efetuem login usando seu próprio ID de usuário (e senha) e depois usem sudoprogramas semelhantes para operar com rootprivilégios quando necessário.

Caso contrário, os principais motivos para não executar como root são:

  • Minimize o risco de danos causados ​​por acidentes. Se você roda rm -fr / home/me/my-subdircomo root, acaba de eliminar drasticamente tudo de importante da sua máquina por causa desse espaço após a (primeira) barra - porque o que aparece primeiro é o que foi adicionado primeiro - pequenas coisas como o kernel, o /bine o /etcdiretório. O Unix fica chateado se você os perder.

  • Minimize o risco de danos causados ​​por sites externos maliciosos. Se você navegar como root, ficará mais vulnerável a downloads de material malicioso.

Eu uso o MacOS X mais do que o Ubuntu, mas lá, o root está desativado por padrão e ainda está na minha máquina. Eu atualizo rotineiramente o kernel e outras operações similares - usando sudo(nos bastidores). Técnicas semelhantes se aplicam ao Linux em geral.

Basicamente, você só deve usar os privilégios onipotentes de rootperíodos de trabalho abreviados para evitar o risco de erros.


1
Não se trata de culpar alguém, é ser capaz de descobrir por que alguém fez uma mudança.
jippie

2
@jippie: Eu quero dizer 'culpa', da mesma maneira que um VCS rastreia quem fez o que, para que a pessoa correta seja atribuída à responsabilidade pela mudança, boa ou má, e um dos nomes do comando que faz esse rastreamento é 'culpa'. Dá a você uma pessoa com quem conversar para descobrir por que algo aconteceu. Nem sempre é uma "falha" (embora com frequência deprimente, a razão para a necessidade de saber seja porque algo não está funcionando como o esperado e é necessário saber por que não). Portanto, trata-se de responsabilidade e rastreabilidade, em vez de necessariamente culpar a pessoa pelo que fez.
perfil completo de Jonathan Leffler

No Ubuntu, comandos como rm -fr / home/me/my-subdir, na verdade, não tentam excluir recursivamente /, porque /são tratados especialmente para se proteger contra esses erros. Consulte a documentação das opções --preserve-roote para obter detalhes. Mas o princípio é som: erros de digitação de caracteres simples que existem que resultam em exclusão de tudo. Por exemplo, se você deseja remover tudo no diretório atual executando , mas acidentalmente colocar um antes , isso seria ruim. --no-preserve-rootman rmrmrm -r */*
Eliah Kagan

@EliahKagan Mas ainda assim, se você fosse ... chown -R nobody:nobody ../digamos / etc, isso protegeria você? Se você fizesse isso em / etc, isso causaria um mundo de mágoa. Da mesma forma, é .*ao executar recursivamente um comando.
Pryftan

21

TL; DR: faça as coisas como root somente quando for necessário. sudotorna isso muito fácil. Se você habilitar logins raiz, ainda poderá seguir esta regra, basta ter cuidado para fazer isso. Embora a ativação de logins raiz não seja realmente insegura se feita corretamente, você não precisa habilitar logins raiz porque é sudo.

Há realmente duas perguntas relacionadas aqui.

  • Por que é ruim fazer login como raiz para o uso diário do computador (navegação na web, email, processamento de texto, jogos etc.)?
  • Por que o Ubuntu padrão para desabilitar logins raiz completamente e usando sudoe polkit para permitir que administradores para executar comandos específicos como root?

Por que não executar tudo como root o tempo todo?

A maioria das outras respostas cobre isso. Tudo se resume a:

  1. Se você usar poderes de raiz para tarefas que não os exigem e acabar fazendo algo que não pretendia fazer, poderá alterar ou prejudicar seu sistema de uma maneira que não deseja.
  2. Se você executar um programa como root quando não precisava, e isso acaba fazendo algo que você não quis dizer para ele fazer - por exemplo, devido a uma vulnerabilidade de segurança ou outro bug - que poderia mudar ou danos seu sistema de uma maneira que você não deseja.

É verdade que, mesmo sem fazer as coisas como raiz, você pode causar danos. Por exemplo, você pode excluir todos os arquivos em seu próprio diretório pessoal, o que geralmente inclui todos os seus documentos, sem ser executado como root! (Espero que você tenha backups.)

Obviamente, como raiz, existem outras maneiras de destruir acidentalmente esses mesmos dados. Por exemplo, você pode especificar o of=argumento errado para um ddcomando e gravar dados brutos nos seus arquivos (o que os torna muito mais difíceis de recuperar do que se os tivesse excluído).

Se você é a única pessoa que usa seu computador, o dano que você pode causar apenas como root pode não ser realmente maior do que o dano que você pode causar com seus privilégios regulares de usuário. Mas isso ainda não é motivo para expandir seu risco e incluir maneiras adicionais de bagunçar o sistema Ubuntu.

Se correr com uma conta de usuário non-root impediu de exercer controle sobre seu próprio computador, então este seria, evidentemente, um mau compromisso. Mas isso não acontece - sempre que você realmente deseja executar uma ação como raiz, pode fazê-lo com sudoe outros métodos .

Por que não possibilitar o login como root?

A ideia de que a capacidade de efetuar login como raiz é inerentemente insegura é um mito. Alguns sistemas têm uma conta raiz ativada por padrão; outros sistemas usam sudopor padrão e alguns são configurados com ambos.

  • Por exemplo, o OpenBSD , que é amplamente e razoavelmente considerado o sistema operacional de uso geral mais seguro do mundo, é fornecido com a conta raiz ativada para login local com senha.
  • Outros SOs respeitados que fazem isso incluem RHEL , CentOS e Fedora .
  • O Debian (do qual o Ubuntu deriva ) faz com que o usuário decida qual abordagem será configurada durante a instalação do sistema.

Não é objetivamente errado ter um sistema em que a conta raiz esteja ativada, desde que

  1. você ainda o usa apenas quando realmente precisa, e
  2. você restringe o acesso a ele adequadamente.

Freqüentemente, os novatos perguntam como habilitar a conta root no Ubuntu. Não devemos ocultar essas informações, mas geralmente quando as pessoas perguntam isso, é porque estão com a impressão errada de que precisam ativar a conta raiz. De fato, isso quase nunca é necessário; portanto, ao responder a essas perguntas, é importante explicar isso. A ativação da conta root também facilita a complacência e a execução de ações como root que não exigem privilégios de root. Mas isso não significa permitir que a conta root é por si só inseguro.

sudoincentiva e ajuda os usuários a executar comandos como root somente quando necessário. Para executar um comando como raiz, digite sudo, um espaço e, em seguida, o comando Isso é muito conveniente, e muitos usuários de todos os níveis de habilidade preferem essa abordagem.

Resumindo, você não precisa habilitar logins raiz porque possui sudo. Mas, desde que você o utilize apenas para tarefas administrativas que exijam, é igualmente seguro habilitar e fazer logon como root, desde que seja apenas das seguintes formas :

  • Localmente, a partir de um console virtual não gráfico .
  • Com o sucomando, quando conectado a partir de outra conta.

No entanto, riscos de segurança adicionais substanciais surgem se você efetuar logon como root das seguintes maneiras:

  • Graficamente. Quando você faz login graficamente, muitas coisas são executadas para fornecer a interface gráfica, e você acaba executando ainda mais aplicativos como root para usar essa interface para qualquer coisa. Isso contraria o princípio de apenas executar programas como root que realmente precisam de privilégios de root. Alguns desses programas podem conter erros, incluindo erros de segurança.

    Além disso, há um motivo não relacionado à segurança para evitar isso. O login gráfico como root não é bem suportado - como o loevborg menciona , os desenvolvedores de ambientes de desktop e de aplicativos gráficos geralmente não os testam como root. Mesmo que isso aconteça, o logon em um ambiente gráfico de área de trabalho como raiz não recebe testes alfa e beta do mundo real pelos usuários, já que quase ninguém tenta (pelas razões de segurança explicadas acima).

    Se você precisar executar um aplicativo gráfico específico como root, poderá usargksudo ou sudo -H. Isso executa muito menos programas como root do que se você realmente fez logon graficamente com a conta root.

  • Remotamente. Com rootefeito, a conta pode fazer qualquer coisa e tem o mesmo nome em praticamente todos os sistemas Unix. Ao fazer login como root via sshou outros mecanismos remotos, ou mesmo configurando serviços remotos para permitir isso , você facilita a invasão de invasores, incluindo scripts automatizados e malware em execução em redes bot, para obter acesso por força bruta, ataques de dicionário (e possivelmente alguns bugs de segurança).

    Indiscutivelmente, o risco não é extremamente alto se você permitir apenas logins raiz com base em chave e não em senha .

Por padrão no Ubuntu, nem os logons de raiz gráficos nem os remotos via SSH são ativados, mesmo se você ativar o login como raiz . Ou seja, mesmo se você habilitar o login raiz, ele ainda estará ativado apenas de maneiras razoavelmente seguras.

  • Se você executa um servidor ssh no Ubuntu e não mudou /etc/sshd/ssh_config, ele conterá a linha PermitRootLogin without-password. Isso desativa o login raiz com base em senha, mas permite o login baseado em chave. No entanto, nenhuma chave é configurada por padrão; portanto, a menos que você tenha configurado uma, isso também não funcionará. Além disso, o login raiz remoto baseado em chave é muito menos ruim que o login raiz remoto baseado em senha, em parte porque não cria o risco de força bruta e ataques de dicionário.
  • Embora os padrões devam protegê-lo, acho que ainda é uma boa ideia verificar sua configuração ssh, se você deseja ativar a conta root. E se você estiver executando outros serviços que fornecem login remoto, como ftp, verifique-os também.

Em conclusão:

  • Faça coisas como root somente quando precisar; sudoajuda você a fazer isso, enquanto ainda oferece todo o poder de root a qualquer momento.
  • Se você entender como o root funciona e os perigos de usá-lo, ativar a conta raiz não é realmente problemático do ponto de vista da segurança.
  • Mas se você entende isso, também sabe que quase certamente não precisa habilitar a conta raiz .

Para obter mais informações sobre raiz e sudo, incluindo alguns benefícios adicionais sudoque não foram abordados aqui, recomendo o RootSudo no wiki de ajuda do Ubuntu.


'Se você é a única pessoa que usa o seu computador, o dano que você pode causar apenas como root pode não ser realmente maior do que o dano que você pode causar nos seus privilégios regulares de usuário. Mas ainda não há razão para expandir seu risco. ”Sem mencionar que isso coloca você no hábito disso ... então você vai para outro sistema e o que acontece? O mesmo acontece com a idéia absurda de fazer as pessoas se acostumarem com o rm -iapelido de shell. Você vai para um sistema que não tem isso e depois o que? Bebês sentados como usuários de erros como esse nunca são uma boa ideia quando se considera que os humanos são criaturas de hábitos.
Pryftan

13

A conta raiz está desativada por padrão - o que significa que ela existe, mas não é utilizável (exceto no modo de recuperação). Isso significa que um invasor está ciente de sua conta root, mas não poderia usá-la, mesmo que tivesse a senha root. Portanto, um invasor precisa adivinhar um nome de usuário com privilégios de administrador E a senha do usuário (o que é muito mais difícil do que apenas tentar descobrir a senha root). No XP, se você tiver o Console de recuperação instalado, qualquer pessoa que tem acesso físico à sua caixa pode inicializar nela (RC) - nenhuma senha é necessária. Igual ao modo de recuperação no Ubuntu.

No Ubuntu, quando dizem que a raiz está desativada - o que realmente significa é que a conta está bloqueada. Uma conta é bloqueada alterando a senha para um valor que não corresponde a nenhum valor criptografado possível. Isso efetivamente impede que alguém possa efetuar login como root - já que não haveria maneira possível de inserir a senha. Como ainda há momentos em que o acesso root é necessário - o kernel do Ubuntu foi modificado para permitir o login local raiz apenas no modo de usuário único.

Veja também esta página


Hum. Sem ofensa, mas você pode querer ler o título da pergunta e depois ler os detalhes novamente.
Mussnoon

3
Isso é extremamente útil - e está relacionado à pergunta. Ele está preocupado com as implicações de segurança de habilitar a conta, um pré-requisito para executar como root.
Stefano Palazzo

1
@ Stefano Palazzo: Embora as informações fornecidas possam ser úteis, sinceramente não consigo ver em que parte está a resposta para o que eu precisava saber. Eu li várias vezes.
Mussnoon 5/12/10

Não impede que as pessoas possam fazer login na raiz.
Chad

12

É como armar uma criança com um AK47, enquanto ele pode brincar alegremente com sua arma de paintball. ;)

Quero dizer que está errado, porque você e seus aplicativos terão mais privilégios do que precisam e é aí que as coisas podem e às vezes dão errado :(


5
uma analogia mais inteligente. (^_^)
kit.yang

2
Essa é uma analogia totalmente inadequada. Uma criança com um AK47 pode se matar e outras pessoas. Um usuário unix com acesso root pode, no máximo, tornar seu sistema temporariamente inoperante. (Pode-se sempre reinstalar o sistema operacional e recuperar a operação).
Kbeta 29/04

@ kbeta Você está certo, minha analogia é um pouco desproporcional e exagerada. por favor siga em frente.
Omeid 12/05

@kbeta a analogia é apropriada. o risco não é um sistema inoperável, mas a perda de dados e privacidade. o usuário root pode excluir os dados. use sua fantasia para associar a morte e a perda de dados.
N611x007

11

Ótima pergunta ... Deixe-me responder de um ponto de vista prático:

Quando comecei a usar o Linux, há mais de 10 anos, as principais distribuições não anunciavam o uso de contas não-raiz tanto quanto hoje. Como eu estava acostumado com o Windows, também não vi sentido em usar uma conta de usuário restrita. Em particular porque eu tinha que entrar em "su" com muita freqüência - sudo não era tão popular naquela época. ;-) Então, eu sempre me conectei como root, porque tinha muita manutenção para fazer meu sistema ficar bem configurado. Mas adivinhe, qualquer sistema instalado novo se tornou rapidamente muito instável.

Um problema concreto, por exemplo: eu não tinha tanto espaço de disco rígido reservado para o Linux; aconteceu comigo algumas vezes que eu tinha 0 bytes restantes na minha partição. Talvez eu não seja completamente preciso porque não conheço o mecanismo exato, mas quando você preenche um disco com uma conta não raiz, há sempre alguns kilobytes restantes. Mas se você realmente tem 0 bytes restantes, seu sistema comete erros estranhos e você pode acabar danificando um pouco o sistema, porque há muito software em execução em segundo plano ...

Outra coisa é: essa divisão entre raiz e não raiz mantém seu sistema bem organizado. Como usuário root, você pode ficar tentado a não instalar corretamente seus novos aplicativos, o que deixa você com um sistema de manutenção difícil e sujo.

Mas a coisa boa: as distribuições modernas executam a maioria das tarefas de administração para você; portanto, raramente é necessário mexer nas entranhas do seu sistema Linux com uma conta root. Digitar uma senha periodicamente é suficiente, o restante é feito pelos scripts do distribuidor.

Mas duvido que você não tenha tido problemas no sistema Windows com isso, se usou 95 ou 98. (Pelo menos, tive problemas com isso ...) Devido à falta de uma separação clara entre administrador e usuário comum "tradicional "Os aplicativos do Windows assumem que eles podem fazer qualquer coisa. A Microsoft se envolveu nesse problema ao lançar o Vista. (Implementando efetivamente um mecanismo sudo.) Então as pessoas têm diálogos muito irritantes dizendo "Você não pode fazer isso". Para alguns softwares não compatíveis com o Vista, você precisava de alguns hacks sujos para instalá-lo, mesmo como Administrador ...


"Talvez eu não seja completamente preciso porque não conheço o mecanismo exato, mas quando você preenche um disco com uma conta não raiz, há sempre alguns kilobytes restantes." Talvez você se refira ao diretório perdido + encontrado? Nesse caso, você pode, como administrador, especificar quanto reservar. Quero dizer que o padrão típico é de 5%, mas posso estar errado e pode ser alterado. É bastante útil, mesmo que raramente necessário. Aparentemente, há mais sobre ele aqui (Lembro-me de meus anos de uso): unix.stackexchange.com/questions/18154/...
Pryftan

Apropriadamente, não se limita aos sistemas de arquivos ext: unix.stackexchange.com/questions/7950/…
Philip

Sim. Eu sabia disso :) Mas obrigado por adicionar isso também.
Pryftan

10

Existem muitos aspectos por trás dessa abordagem. Alguns deles são:

  • Raiz é toda poderosa.
  • Nos sistemas Unix e Unix-like, os privilégios de administração do sistema são tudo ou nada. Um usuário tem acesso root ou não, e o acesso root implica o controle completo de uma máquina. Se a máquina em questão for usada por mais de uma pessoa ou o root tiver acesso a outros sistemas ou arquivos de usuários, é mais aceitável conceder a alguns usuários privilégios de root parciais.

  • O usuário root pode ocultar todas as suas ações.
  • O sudo registra todos os comandos executados via sudo. Ter um registro do que está sendo feito com o sudo nos ajuda a diagnosticar problemas com sistemas / processos individuais e problemas gerais de configuração, além de nos ajudar a identificar as melhorias necessárias.

  • A senha root fornece acesso a qualquer comando em um sistema.
  • Através do seu arquivo de configuração, o sudo pode fornecer ao usuário acesso root para um conjunto específico de comandos. Isso também evita o efeito "tudo ou nada", permitindo que usuários individuais tenham mais controle sobre suas máquinas e ajudem a resolver problemas comuns.

    Aqui está um bom artigo: http://cf.stanford.edu/policy/root


    Mas quando você tem sudo completo, você pode sudo su e oculta suas ações.
    Wilhelm Erasmus

    8
    rm /*
    

    Digamos que você esteja limpando uma área administrativa. Você se cansa de senha, então você sudo su. Você se distrai só por um segundo e esquece que toca /. Então você rm *. Eu fiz isso. Você pode recuperar tudo, mas é uma PITA. Ah, e também desceu /media!


    10
    Sempre reclamamos que o PC está muito lento, mas é como se eles fossem otimizados para executar uma empresa assim o mais rápido possível.
    jippie

    1
    @jippie Porque o RM apenas destrói o link do inode para o arquivo. Não demora muito para excluir um link e marcar um espaço como "livre".
    Kaz Wolfe

    @jippie, ele deve ter uma construção em 10 segundos de contagem regressiva
    HopefullyHelpful

    7

    Por que não ter login root?

    Embora você possa criar uma senha para a conta de superusuário, permitindo que você faça login como root, vale ressaltar que essa não é a maneira "Ubuntu" de fazer as coisas. O Ubuntu optou especificamente por não fornecer um login e senha root por padrão por um motivo. Em vez disso, será usada uma instalação padrão do Ubuntu sudo.

    Sudo é uma alternativa para fornecer às pessoas uma senha root, a fim de executar tarefas de superusuário. Em uma instalação padrão do Ubuntu, a pessoa que instalou o sistema operacional recebe permissão "sudo" por padrão.

    Qualquer pessoa com permissão "sudo" pode executar algo "como superusuário", aguardando sudoseu comando. Por exemplo, para executar apt-get dist-upgradecomo superusuário, você pode usar:

    sudo apt-get dist-upgrade
    

    Benefícios da abordagem sudo

    • Com o sudo, você escolhe antecipadamente quais usuários têm acesso ao sudo. Não é necessário que eles se lembrem de uma senha root, pois eles usam sua própria senha.

    • Se você tiver vários usuários, poderá revogar o acesso de superusuário apenas removendo sua permissão sudo, sem precisar alterar a senha root e notificar a todos sobre uma nova senha.

    • Você pode até escolher quais comandos um usuário pode executar usando sudo e quais comandos são proibidos para esse usuário.

    • E, por último, se houver uma violação de segurança, em alguns casos, poderá deixar uma trilha de auditoria melhor mostrando qual conta de usuário foi comprometida.

    O Sudo facilita a execução de um único comando com privilégios de superusuário. Com um login root, você permanece permanentemente em um shell de superusuário que deve ser encerrado usando exitou logout. Isso pode levar as pessoas a permanecer no shell do superusuário por mais tempo do que o necessário, apenas porque é mais conveniente do que fazer logoff e logon novamente mais tarde.

    Com o sudo, você ainda tem a opção de abrir um shell de superusuário permanente (interativo) com o comando:

    sudo su
    

    ... e isso ainda pode ser feito sem nenhuma senha root, porque sudoconcede privilégios de superusuário ao sucomando.

    E da mesma forma, em vez de su -usar um shell de login, você pode usar sudo su -ou até mesmo sudo -i.

    No entanto, ao fazer isso, você só precisa estar ciente de que está agindo como um superusuário para cada comando. É um bom princípio de segurança não permanecer como superusuário por mais tempo do que o necessário, apenas para diminuir a possibilidade de causar acidentalmente algum dano ao sistema (sem ele, você só pode danificar os arquivos que o usuário possui).

    Apenas para esclarecer, você pode , se preferir, fornecer ao usuário root uma senha que permita logins como root, se você desejar especificamente fazer as coisas dessa maneira. Eu só queria que você soubesse sobre a convenção do Ubuntu de preferir sudoe tente explicar alguns dos motivos pelos quais o Ubuntu favorece essa abordagem como padrão.

    Por que não permitir o login root no SSH?

    Mesmo se o usuário raiz não tiver uma senha que lhe permite autenticar como root, ainda é uma boa prática de segurança para desativar login root directa do exterior, como em SSH. É razoável que os usuários tenham que su -ou sudoapós o login inicial.

    Os benefícios potenciais para isso estão principalmente relacionados à segurança:

    • Reduz o vetor de ataque, removendo a possibilidade de forçar brutalmente a senha root remotamente. É comum que um servidor na Internet seja constantemente bombardeado por tentativas de forçar brutalmente a senha de root via SSH.

    • Ele cria uma melhor trilha de auditoria de modo que, mesmo no caso de violação, onde o atacante faz obter privilégios de superusuário mais tarde, você pode ver cuja conta de usuário foi utilizado para ganhar acesso.


    6

    Quando logado como root, é possível que aplicativos, scripts ou comandos da linha de comando acessem partes sensíveis do software que podem danificar o sistema. Isso pode ser resultado de inexperiência por parte do usuário ou programador ou devido ao código oculto malicioso.


    5

    É muito fácil bagunçar ao operar como root. Você pode derrotar todo o sistema como um comando ...


    5

    Posso acrescentar que há uma diferença entre o Administrador no Windows e a raiz no Unix. O administrador ainda possui algumas restrições nos sistemas, onde o root não possui nenhuma restrição. O análogo correto da raiz no Windows é usuário do sistema .

    O ruim de usar o PC na raiz / Sistema é que você pode destruir acidentalmente qualquer coisa sem nenhum aviso do sistema operacional.


    3

    Razões contra o uso de root:

    • Pode destruir acidentalmente arquivos do sistema
    • Pode ter uma infecção
    • Não registra ações

    Razões para usar o root:

    • Acesso a tudo, sem senhas de digitação
    • GUI, sem usar terminais para gerenciar arquivos / diretórios do sistema

    Parece-me que uma conta não raiz ainda pode ser vítima desses motivos contra o uso da raiz, o máximo que ela adiciona é uma confirmação de suas ações. Eu acho que, desde que você saiba o que está fazendo, estará perfeitamente seguro usando o root. Lá, eu disse.


    Embora tecnicamente exista uma maneira de registrar ações, incluindo todos os comandos. Isso vale para todos os usuários. Veja a contabilidade de processos, por exemplo, aqui: linuxjournal.com/article/6144 E isso só é realmente seguro se você precisar ser root; caso contrário, não é totalmente seguro (exploração, etc.), mesmo que o comando seja seguro.
    Pryftan

    3

    Se os aplicativos forem executados como raiz, não há garantia de que nenhum deles executaria

    rm -rf /
    

    (Este é um exemplo de um comando que não deve ser executado.)


    @StefanoPalazzo Esta postagem não faz sentido com o comando removido, então revirei sua edição - você também pode ter excluído a postagem. Observe que, ao contrário do equívoco generalizado, este comando, conforme escrito, na verdade não exclui arquivos quando executado em um sistema Ubuntu, mas é semelhante aos comandos que o fazem. Portanto, se você estava preocupado, alguém poderia, sem pensar, copiar o comando e acionar o sistema deles, isso não é provável. Consulte a documentação das opções --preserve-roote para obter detalhes. --no-preserve-rootman rm
    Eliah Kagan

    Solaris trata este comando como um comportamento indefinido de acordo com uma interpretação ampla POSIX (e Bryan Cantrill) e gera um erro
    Jeremy Hajek

    3

    Dado um usuário experiente e cuidadoso, não tenho certeza de que exista uma resposta certa . Eu não tinha visto essa resposta, então pensei em entrar.

    O que eu não gosto é de alterações não intencionais de permissões em sistemas multiusuários que eu preciso chmodmais tarde. A correção via chmod após o fato é muito mais irritante do que precisar do sudo, mas depende do que eu planejei.


    3

    Não há perigo no log como root se usado com cuidado.

    Embora eu ache que desabilitar o root é uma solução preferível, porque o invasor não pode forçá-lo a forçar.

    Uma solução é criar usuário no grupo sudo com nome obscuro, curtir gamere usar o sudo para executar tarefas administrativas.

    Portanto, o invasor deve não apenas adivinhar a senha desse usuário administrativo, mas também o nome de login. O que não é óbvio se o usuário usando sudo tem nome de login, como kittyou gamerou algo similar.


    2

    O software é baseado em bibliotecas compartilhadas, dependências, arquivos de configuração etc.
    Na maioria das vezes, um único clique em um aplicativo invoca uma "reação em cadeia" de várias alterações, não apenas onde você acha que provavelmente.
    Quando essas alterações estão prestes a afetar as configurações críticas do sistema, é bom que você - como usuário - saiba.
    É por isso que o acesso root é um bom modelo de segurança:
    se algo crucial está prestes a acontecer com o seu sistema, você será notificado ao solicitar a elevação de privilégios.


    1

    É um problema de duas caras com mais de uma resposta.

    Para alguma realidade, verifique as respostas sempre-mas-oh-tão-terríveis a isso:

    desktop installations:

    • use seu próprio usuário e sudo, se necessário, caso contrário, um vetor de ataque usado com sucesso porque você realmente não sabe o que está fazendo e seu sistema está comprometido
    • nas empresas maiores, é possível que você nem tenha privilégios de root em sua própria estação de trabalho, mesmo se for administrador, dependendo da quantidade de chapéus de papel alumínio.

    server installations:

    • existe uma grande diferença entre tornar suas sessões curtas de trabalho legítimas como raiz (desde que você tenha logins sem senha, gerenciamento adequado de chaves ssh para todos os servidores - e fail2ban configurado para todos os logins de senhas enquanto estiver fazendo isso) e ter todos os daemon / serviços executando com seu próprio usuário (o que é obrigatório) - a maioria das pessoas parece não perceber a diferença
    • por diversão: tente usar suas ferramentas de gerenciamento de configuração controladas por versão (ansible / puppet / salt / qualquer que seja com arquivos de um servidor git) apenas sem acesso root. (você possui alguma forma de AAA para esses sistemas especiais, bem como para seus sistemas de monitoramento e backup, não é?)
    • também: o padrão rm -rf /não funciona na maioria das distribuições convencionais IIRC
    • qualquer local de trabalho sério possui um host jumphost / bastião para acessar a frota de servidores que registra tudo o que você faz de qualquer maneira, o que provavelmente é protegido ainda mais pelo 2FA
    • se você tiver sudo e nenhum jumphost, poderá consertar os logs do host para terminar como desejar, de qualquer maneira, se não forem espelhados em tempo real, é isso.
    • quando os logs ssh também são 'limpos', não é possível provar que você esteve no host, se não houver outro sistema de monitoramento de rede em vigor

    Para qualquer tamanho de empresa (leia-se: SOHO provavelmente com um IP estático) entre esses dois extremos que carecem de medidas decentes de monitoramento / backup / automação / registro, pode ser útil reforçar o uso do sudo nos servidores. (Que é contornado por pessoas que fazem o sudo su -mais rápido possível após a conexão, deixando todas as suas intenções de registrar o que aconteceu serem desperdiçadas, mesmo sem intenções maliciosas, assim que mais de um usuário root é logado. Boa sorte mudando isso através de procedimentos forçados e tratando pessoas com draconianos. medidas por não obedecer às regras. A vida sempre encontra um caminho.)

    Mas se você não possui pelo menos fail2ban para proteger seus logins de senhas (se houver algum presente, especialmente nos sistemas voltados para a Internet), lembre-se de lidar com senhas (ferramentas de gerenciamento de senhas, políticas de retenção, sem senhas mestras, manipulá-las com funcionários) flutuações ...) e tenha alguma forma de gerenciamento de atualizações adequado para a frota de servidores, para que todos os servidores sejam corrigidos regularmente, você provavelmente será invadido algum dia de qualquer maneira, seja de dentro ou de fora.

    E sempre ter usado sudoreligiosamente e ter aplicado seu uso entre todas as pessoas não mudará sua probabilidade de ser possuído muito nesse caso.


    Finalmente, uma resposta real e diferenciada, em vez dos mantras usuais "nunca faça isso". +1 e obrigado por isso.
    Andreas H.

    0

    Em última análise, não há mal em executar como root. São apenas algumas pessoas paranóicas que acham impossível reinstalar um sistema operacional. O argumento "Alguém pode comprometer um programa ..", e daí? se eles fizerem isso, eles já poderão digitar sua senha com senha ou apenas exibir uma solicitação de senha raiz de qualquer maneira e solicitar a senha. Sopre seu sistema porque você seleciona tudo em / e exclui? oh bem, saia do instalador e reinstale. Demora menos de 20 minutos, tome um café e leve à geladeira. Raiz é bom, eu tenho rodado root desde que me lembro e você sabe o que faz? Isso torna a instalação de pacotes menos dolorosa. Você não precisa digitar a senha root a cada 5 minutos, como normalmente precisa. Você não encontra problemas ao tentar salvar / editar arquivos de configuração do sistema porque eles ' Apenas permissões de root. É muito mais fácil e melhor executar como root.

    Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
    Licensed under cc by-sa 3.0 with attribution required.