Acesso root que não pode alterar a senha do root?

Question

Estamos com um pequeno problema em um servidor. Queremos que alguns usuários possam fazer, e. sudo e tornar-se root, mas com a restrição de que o usuário não pode alterar a senha do root. Ou seja, uma garantia de que ainda podemos fazer login nesse servidor e nos tornar root, não importando o que os outros usuários farão.

Isso é possível?

    

Answer 1

We want that some users should be able to do e.g. sudo and become root,

Bem, esse é o problema que o sudo é projetado para resolver, então essa parte é bastante fácil.

but with the restriction that the user can't change root password.

Você pode, como SHW apontou em um comentário, configurar o sudo para permitir que apenas algumas ações sejam tomadas como root por determinados usuários. Ou seja, você pode permitir que o usuário1 execute sudo services apache2 restart , permita que o usuário2 execute sudo reboot , mas nada mais, enquanto permite que o user3 contratado como administrador do sistema faça sudo -i . Há howtos disponíveis sobre como configurar o sudo assim, ou você pode pesquisar (ou perguntar) aqui. Esse é um problema solucionável.

No entanto, um usuário que tenha recebido a capacidade de sudo -i ou sudo em um shell ( sudo bash , por exemplo) pode fazer qualquer coisa. Isso porque no momento em que o sudo lança o shell, o próprio sudo está fora de questão. Ele fornece o contexto de segurança de um usuário diferente (na maioria das vezes root), mas não tem voz no que o aplicativo executado faz. Se esse aplicativo, por sua vez, lançar passwd root , não há nada que o sudo possa fazer sobre isso. Note que isso pode ser feito através de outros aplicativos também; por exemplo, muitos dos editores mais avançados fornecem recursos para executar um comando através do shell, um shell que será executado com o uid eficaz desse processo de edição (isto é, root).

That is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

Desculpe; se você realmente quer dizer "garantir que poderemos fazer o login e usar o sistema, não importa o que alguém com acesso root faça a ele", isso (para todos os efeitos) não pode ser feito. Um rápido "sudo rm / etc / passwd" ou "sudo chmod -x / bin / bash" (ou o que a raiz do shell usa) e você é praticamente escolhido de qualquer maneira. "Pretty hosed" significa "você precisará restaurar a partir de backup e espero que eles não fizeram nada pior do que um deslize de dedos". Você pode tomar algumas medidas para reduzir o risco de um acidente acidental levando a um sistema inutilizável, mas não pode evitar que a malícia cause problemas muito sérios até e incluindo o ponto de precisar reconstruir o sistema a partir do zero ou, no mínimo, de bons backups conhecidos.

Ao fornecer acesso irrestrito ao sistema para um usuário, você confia nesse usuário (incluindo qualquer software que ele possa escolher para executar, até mesmo algo tão mundano quanto ls) para não ter intenção maliciosa e não atrapalhar por acidente. Essa é a natureza do acesso root.

Acesso raiz limitado por meio de O sudo é um pouco melhor, mas você ainda precisa tomar cuidado para não abrir nenhum vetor de ataque. E com o acesso root, há muitos possíveis vetores de ataque para ataques de escalonamento de privilégios.

Se você não pode confiar neles com o nível de acesso que o root implica, você precisará de uma configuração de sudo apertada very , ou simplesmente não conceder ao usuário em questão acesso root em todos os meios, sudo ou de outra forma.

    

Answer 2

Isso é praticamente impossível. Primeiro de tudo, se você lhes der o poder de se tornar root , então não há nada que você possa fazer para evitar que eles façam algo. No seu caso de uso, sudo deve ser usado para conceder a seus usuários alguns poderes de root enquanto restringe outros sem permitir que eles se tornem root .

Em seu cenário, você precisaria restringir o acesso aos comandos su e passwd e abrir o acesso a praticamente todo o restante. O problema é que não há nada que você possa fazer para impedir que seus usuários editem diretamente /etc/shadow (ou /etc/sudoers ) e descartem uma senha de root substituta para seqüestrar root. E este é apenas o cenário mais simples de "ataque" possível. Sudoers com poder irrestrito, exceto por um ou dois comandos, podem contornar as restrições para seqüestrar acesso root completo.

A única solução, como sugerido por SHW nos comentários é usar sudo para conceder aos usuários acesso a um conjunto restrito de comandos.

Atualizar

Pode haver uma maneira de fazer isso se você usar tíquetes Kerberos para autenticação. Leia este documento explicando o uso do arquivo .k5login .

cito as partes relevantes:

Suppose the user alice had a .k5login file in her home directory containing the following line:
[email protected]
This would allow bob to use Kerberos network applications, such as ssh(1), to access alice‘s account, using bob‘s Kerberos tickets.
...
Note that because bob retains the Kerberos tickets for his own principal, [email protected], he would not have any of the privileges that require alice‘s tickets, such as root access to any of the site’s hosts, or the ability to change alice‘s password.

Eu posso estar enganado, no entanto. Eu ainda estou vasculhando a documentação e ainda não testei o Kerberos.

    

Answer 3

Suponho que você queira ter um acesso de "administrador de emergência", mesmo que o seu administrador atual aumente (mas, além disso, você confia totalmente no administrador principal).

Uma abordagem popular (embora muito agressiva) é ter um segundo usuário com uid=0 , comumente chamado de toor (root backwards). Tem uma senha diferente e pode servir como um acesso de backup. Para adicionar, você provavelmente precisará editar /etc/passwd e /etc/shadow (copie as root linhas).

É tudo, menos à prova de falhas, mas se você só precisa proteger contra o "administrador principal", alterando a senha sem aviso prévio, então ele vai funcionar. É fácil desabilitar, removendo a conta toor ; então o único benefício é ter uma senha separada.

Alternativamente, você pode querer procurar mecanismos alternativos de autenticação, por exemplo, ssh keys, libnss-extrausers , LDAP etc.

Note que o administrador ainda pode estragar mal. Por exemplo, bloqueando o firewall.

Se você quer ter um sistema muito seguro, considere usar o SELinux, onde o usuário unix (por exemplo, root) também vem com uma função, que pode ser muito mais granulada. Talvez você queira conceder ao seu usuário acesso root, mas apenas uma função restrita (por exemplo, para administrar somente o apache). Mas isso exigirá muito esforço do seu lado para configurar corretamente a política.

    

Answer 4

A essência do root é ter um comando irrestrito do sistema. Você poderia ajustá-lo com o SELinux (costumava haver um site de demonstração onde qualquer um poderia fazer logon como root, mas seu poder era prejudicado pelo sistema de acesso), mas esse não é o ponto. O ponto é que esta é a solução errada para o seu problema.

Agora, você não disse qual é o seu problema, mas se você não confia que esses usuários mantenham suas mãos longe da senha de root, eles não precisam ser root. Se precisarem para administrar o servidor da Web, ou vários dispositivos de hardware, ou a unidade de distorção ou qualquer outra coisa, configure uma solução para isso. Crie um grupo super-poderoso, dê a ele todo o acesso necessário e adicione-o a ele. Se eles precisarem executar chamadas de sistema apenas de raiz, escreva alguns programas setuid.

É claro que um usuário com esse tipo de acesso (e um pouco de conhecimento) pode facilmente hackear o sistema, mas pelo menos você está trabalhando com o modelo de segurança do sistema operacional, e não contra ele.

PS. Existem muitas maneiras de organizar o acesso root sem a senha; por um lado, se você estiver em /etc/sudoers (sem restrições), você só precisará da sua própria senha para se tornar root, por exemplo, com sudo bash . Mas você simplesmente não precisa ir até lá.

    

Answer 5

É provavelmente possível, pelo menos em teoria, fazer isso usando o SELinux. Isso permite que você defina regras muito mais precisas sobre o que um usuário ou processo é ou não pode fazer. Mesmo com o SELinux, pode ser complicado impedir que um usuário altere a senha do root, mas ainda assim seja capaz de fazer o que for necessário.

Realmente, depende do que o usuário que não tem permissão para alterar a senha raiz realmente precisa ser capaz de fazer. Provavelmente seria mais fácil e seguro apenas descobrir o que é isso e conceder essas permissões especificamente usando o sudo.

    

Answer 6

Talvez você deva considerar permitir que os usuários tenham acesso root a uma máquina virtual ou contêiner LXC. Isso permitiria que eles tivessem acesso root completo a um sistema, sem impedi-los de fazer login no host ou executar ações administrativas.

    

Answer 7

Eu não sei se será praticamente viável, mas aqui está um hack sujo:

1. escreva um script / programa de wrapper que copie o arquivo /etc/passwd para algum outro local, antes de chamar% realsudo
2. Permitir que o usuário normal use sudo
3. Uma vez que ele terminou sua tarefa, ou quando ele saiu do sudo, restaure o arquivo /etc/passwd

Eu sei, há muitas outras coisas que você deve considerar para conseguir isso. Afinal, é um hack sujo

    

Answer 8

A declaração de que sudo é apenas para concessão de raiz e não há proteção depois disso é descaradamente falso.

Você usa visudo para modificar o arquivo sudoers. Aqui está uma linha de exemplo:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandro é o nome de usuário para o qual estamos dando permissão. Coloque um % na frente para aplicá-lo a um grupo.
• ALL é um nome para esta regra. Sudoers podem fazer muito mais do que apenas conceder permissões globais. É aí que fica complicado embora.
• = não precisa de explicação
• ALL:ALL lê como (who_to_run_it_as: what_group_to_run_it_as). Dessa forma, você pode permitir a execução de um comando, mas apenas no contexto de um usuário ou grupo específico.
• NOPASSWD : informa para desativar o prompt de senha.
• /path/to/command permite especificar comandos específicos path_to_commmand, another_command

O importante é lembrar que, embora sudo seja usado principalmente por usuários domésticos para escalar privilégios de root, ele pode ser usado para controlar o acesso a comandos específicos de maneira muito mais granular.

Referências

• da minha outra resposta aqui

Answer 9

(eu não sei ubuntu, mas deve ser semelhante ao Fedora / Red-Hat) A única coisa que posso imaginar ao restringir o acesso à alteração da senha do root é não dar acesso root completo, talvez com sudo, ou usar o SElinux para restringir o acesso ao arquivo de senhas ... mas eu não confiaria tanto com muito acesso quanto O root geralmente tem acesso irrestrito e pode atualizar o SElinux, ou reclassificar o arquivo de senhas, ou executar algum programa pré-pré-configurado para alterar a senha.

Se você não confia neles o suficiente para não alterar a senha, provavelmente não deveria estar dando acesso root. Caso contrário, eu acho que você está tentando evitar acidentes.

Se você está apenas tentando proteger seu acesso ao root, configure um programa que possa restaurar a senha de root, para que, mesmo que seja alterado, possa ser restaurado com acesso mínimo. (sudo faz bem por conta própria)

    

Answer 10

Sua exigência é:

We are having a little problem on a server [...] that is, a guarantee that we still can login to that server and become root no matter of what the other users will do.

A partir da sua pergunta, parece que você não está enfrentando usuários mal-intencionados aleatórios com a intenção de destruir seu sistema, mas sim usuários semi-confiáveis que podem causar danos de vez em quando (estudantes, talvez?). Minhas sugestões abordam essa situação, não um ataque total por usuários mal-intencionados.

1. Execute o servidor dentro de um ambiente virtual. Você poderá montar o sistema de arquivos do servidor e substituir arquivos alterados por versões válidas. Dependendo do possível dano antecipado, você pode tirar um instantâneo de todos os diretórios críticos (/ bin, / sbin, / etc, / usr, / var, etc.) e expandir o instantâneo para sobrescrever os arquivos danificados enquanto deixa o resto do arquivo. sistema intacto.

2. Executa o sistema somente leitura, por exemplo de um DVD-R. Se você pode viver com a maioria das partes do sistema sendo estática até a próxima reinicialização, esta é uma boa opção. Você também pode usar um armazenamento de backup somente leitura com um ambiente virtual ou carregar o sistema básico pela rede, tornando as mudanças entre as reinicializações muito mais fáceis do que gravar um novo DVD-R.

3. Módulos do kernel. Os Módulos de Segurança do Linux (LSM) do kernel fornecem a base para a criação de módulos seguros. O LSM é usado pelo SELinux, mas também é usado por vários sistemas menos conhecidos e mais simples, como Smack, TOMOYO e AppArmor. Este artigo tem uma boa visão geral das opções. As chances são de que uma delas possa ser configurada imediatamente para impedir o acesso de gravação a / etc / passwd, / etc / shadow ou qualquer outro arquivo que você queira, até mesmo pelo usuário root.

4. A mesma ideia como # 1, mas quando o servidor não está em um ambiente virtual. Você poderia ter o servidor carregado em cadeia em um sistema operacional somente leitura, como um live CD, que montaria automaticamente o sistema de arquivos do servidor e sobregravaria o sistema básico em cada inicialização com cópias em bom estado. O sistema operacional somente leitura inicializaria no sistema operacional principal.

5. Novamente, supondo que esses sejam usuários semi-confiáveis e responsáveis por um superior (professor / chefe), a melhor resposta pode ser Auditoria do Linux . Dessa forma, você saberá todas as ações relevantes de segurança tomadas e quem as tomou (você saberá quem as tomou, porque, mesmo que todos os usuários compartilhem a conta raiz, elas serão excluídas da conta de usuário primeiro). Na verdade, você pode até mesmo analisar o log de auditoria em tempo real e substituir os arquivos danificados. / etc / shadow sobrescrito? Não tem problema, basta que o servidor de monitoramento substitua-o instantaneamente por uma versão válida.

Outras tecnologias que você pode querer investigar com base em suas necessidades:

• Arquitetura de medição de integridade do Linux / Módulo de verificação ampliada (IMA / EVM) e
• Módulos de plataforma confiável (TPM).

Answer 11

Para complementar as outras respostas, vou assumir que o cenário é que você percebe perder o controle do root em uma situação rara e, nesses casos, uma reinicialização do servidor é permitida. (Afinal, se você acredita que a máquina foi comprometida, você vai querer colocá-la offline de qualquer maneira.)

A grande vantagem disso é que não há nada para configurar. Sua pergunta se torna: " Esqueci a senha do root, como volto? " E a resposta para isso é reiniciar, e escolher o modo de usuário único quando a máquina for ativada. Isso lhe dá um shell de root sem precisar saber a senha. Nesse ponto, você pode definir uma nova senha. (Assim como ir e reparar qualquer dano ...)

    

Answer 12

Se você clonar seu servidor em uma VM (como VirtualBox ), poderá fornecer acesso irrestrito às pessoas e ainda garanta que você sempre terá acesso direto à (s) partição (ões) do sistema operacional convidado e, portanto, mantenha o controle final sobre /etc/passwd e similares, já que você terá raiz no sistema host.

É claro que dar acesso irrestrito à raiz ainda pode não ser a solução correta: se a segurança de dados for um problema ou sua responsabilidade, você não poderá conceder acesso root.

    

Answer 13

O requisito não é tecnicamente possível. Como já comentamos com eloqüência, conceder direitos de sudo ilimitados ou ainda mais limitados a um usuário significa que você confia nesse usuário. Alguém que tenha intenções malignas e capacidade técnica e perseverança suficientes pode passar por quaisquer obstáculos que sejam colocados em prática.

No entanto, supondo que você possa confiar que seus usuários não sejam mal-intencionados, você pode restringir a senha ao assunto policy . Você pode criar um wrapper para o programa passwd que os lembrará "por favor, não altere a senha do root". Isso supõe que a origem do problema é que os usuários que estão alterando a senha raiz estão fazendo isso devido a um mal-entendido (por exemplo, talvez pensando que estão mudando sua própria senha depois de ter feito sudo bash ).

Em circunstâncias especiais (raras), a confiança se completa não for possível e não for possível dividir o acesso sudo a partes adequadas, mas razoavelmente seguras, pode considerar estabelecer sanções organizacionais contra alteração de senha (ou qualquer outra forma especificada de adulteração do sistema), organizar o monitoramento de recursos críticos para que não seja fácil não ser detectado para contornar as políticas definidas - e ser público e transparente sobre as regras de uso e monitoramento.

O aspecto de monitoramento e descoberta é um problema técnico difícil que se beneficia de outra pergunta caso você opte por seguir esse caminho. Parece-me que precisaríamos

1. detecta quando um usuário altera a identidade para o root e rastreia os processos criados;
2. registre as criações do processo daí em diante para ver quem é o usuário original responsável por cada processo e usando o host remoto em que os usuários parcialmente confiáveis não têm acesso para enviar os logs;
3. use algum tipo de rastreamento do sistema para registrar o que está acontecendo e para mais tarde descobrir quem está por trás da violação da política.

Precisamos, pelo menos, registrar a abertura de um conjunto diferente de arquivos seguros para gravação, criação de processos, exec() e, é claro, qualquer tentativa de alterar a rede.

A implementação pode ser feita por libc modificada ou (muito melhor) rastreamento de chamadas do sistema.

É claro que é impossível fazer com que o rastreamento e o logging funcionem 100% corretamente, não é fácil de implementar e também requer recursos adicionais para operar. Isso não pararia a alteração de senha ou outra adulteração indesejada do sistema, mas tornaria possível (mais provável) encontrar o usuário culpado ou pelo menos criar uma ilusão de que há monitoramento e torná-lo > menos convidando para alguns usuários mal-intencionados (mas alguns hackers amantes de problemas que vêem a futilidade fundamental das medidas técnicas postas em prática podem se sentir encorajados a abraçar o desafio e tentar contornar o sistema apenas por diversão) .

    

Answer 14

A pergunta formulada originalmente é inútil. Parece que o objetivo principal é "ainda ter login", por isso falando sobre alguma entrada de emergência que continua funcionando com certeza, mesmo com acesso root concedido a outra pessoa. Felicidades para Anony-Mousse que primeiro observou explicitamente.

O problema é: Se o dono tiver acesso físico à caixa Ele pode recuperar facilmente o acesso lógico ao sistema (desde que ainda esteja vivo :). Se não, manter a senha do root não salvará, por exemplo, sshd down ou configuração de redes ruins, assim o sistema ainda não está acessível de qualquer maneira.

O tópico sobre como evitar que o sistema seja danificado por uma pessoa com privilégios administrativos parece muito amplo para o formato de pergunta do SE.

Falando sobre a solução remota de emergência, a melhor maneira é IPMI (se eu estiver disponível). O proprietário do sistema pode anexar a unidade virtual a qualquer momento, inicializar a partir dela e procced com a recuperação do sistema.

Se o IPMI não estiver disponível, qualquer tecnologia de virtualização adequada pode ser contornável, como já foi proposto acima.

    

Answer 15

Você pode limitar o acesso ao sudo no seu arquivo /etc/sudoers

Para explicar completamente a sintaxe do / etc / sudoers, usaremos uma regra de amostra e dividiremos cada coluna:

jorge  ALL=(root) /usr/bin/find, /bin/rm

A primeira coluna define a qual usuário ou grupo essa regra sudo se aplica. Neste caso, é o usuário jorge. Se a palavra nesta coluna for precedida por um símbolo%, ela designará esse valor como um grupo em vez de um usuário, já que um sistema pode ter usuários e grupos com o mesmo nome.

O segundo valor (ALL) define a que hosts esta regra sudo se aplica. Esta coluna é mais útil quando você implanta um ambiente sudo em vários sistemas. Para um sistema Ubuntu desktop, ou um sistema onde você não planeja implementar as funções sudo em múltiplos sistemas, você pode se sentir livre para deixar este valor configurado para ALL, que é um caractere curinga que combina todos os hosts.

O terceiro valor é colocado entre parênteses e define em qual usuário ou usuário o usuário na primeira coluna pode executar um comando. Este valor é definido como root, o que significa que jorge terá permissão para executar os comandos especificados na última coluna como o usuário root. Esse valor também pode ser definido para o caractere curinga ALL, o que permitiria que o jorge executasse os comandos como qualquer usuário no sistema.

O último valor (/ usr / bin / find, / bin / rm) é uma lista separada por vírgulas de comandos que o usuário da primeira coluna pode executar como usuário (s) na terceira coluna. Nesse caso, estamos permitindo que o jorge execute o find e o rm como root. Esse valor também pode ser configurado para o caractere curinga ALL, o que permitiria que o jorge executasse todos os comandos no sistema como root.

Com isso em mente, você pode permitir comandos X de maneira delimitada por vírgulas e desde que você não adicione passwd a isso, você deve estar bem

    

Answer 16

Não há 1/2 root :) Depois de dar privilégios de root, eles podem fazer o que quiserem. Alternativamente, você pode usar o sudo para executar um shell restricted bash ou executar o rbash sem privilégios de root.

Se você quiser ter um mecanismo à prova de falhas para acessar o servidor como root, você pode criar outro usuário com uid=0 ou criar um cron simples que irá redefinir a senha root periodicamente.

    

Answer 17

Tente adicionar um grupo de rodas em vez de usar o sudo. sudo permite que um usuário execute como se fosse root, o que significa que não é diferente de executar:

su -

para se tornar root. A raiz uid = 0; a roda uid = 10. As pessoas usam os nomes, mas o sistema operacional usa o uid. Certos comandos não podem ser executados por um membro do grupo de rodas. (Se você usar roda, não cometa o erro de adicionar root como um membro do grupo de rodas). Dê uma olhada na documentação da Red Hat se você não souber o que é a roda.

Outra opção é usar uma chave ssh em vez de uma senha. Supondo que você possa ter certeza de que as pessoas que usam o sudo não adicionam suas chaves públicas ao arquivo ~ / .ssh / authorizedkeys, isso evita qualquer preocupação com a senha do root, porque a senha do root é efetivamente ignorada.

Se você preferir estender a confiança a esses usuários (para não adicionar sua própria chave pública), tente usar atributos de arquivo estendidos e usar o bit Imutável. Depois de criar seu arquivo ~ / .ssh / authorizedkeys, e depois de configurar / etc / ssh / sshd_config e / etc / ssh / ssh_config como quiser, configure o bit Imutável. Claro, existem maneiras de estragar com isso também - nada é perfeito.

Em qualquer sistema, os insiders são o maior risco. A pessoa que comanda o show está no topo da pilha. Um pensamento relacionado diz respeito aos contratos. Os advogados dirão: "Nunca faça negócios com alguém que você precise de um contrato para fazer negócios". O senso comum nos diz: "Nunca faça negócios sem contrato". Quando você encontrar alguém em quem confie o suficiente para fazer negócios, escreva o contrato com base nas necessidades do outro.

Todas as respostas enviadas, incluindo a minha, não abordam o acesso físico. Quem quer que tenha, tem controle. Se não é você, então é provável que você acesse a pessoa que acessa fisicamente a máquina caso alguém encontre uma maneira de impedi-lo de fazer login ou se encontrar uma maneira de fazer o login mesmo depois de você Eu tentei impedir que isso acontecesse. É claro que, se você tiver acesso físico, pode não haver necessidade de nenhuma dessas coisas, embora a implementação de um casal deva ser considerada de qualquer maneira, se você estiver interessado em NÃO ser incomodado.

-John Crout

    

Answer 18

Uma maneira seria garantir que /etc não seja gravável. Por ninguém, contanto que possa haver um sudoer ao redor.

Isso pode ser feito montando-o na rede e garantindo, do outro lado, que o dispositivo não pode ser escrito.

Isso pode ser feito usando um dispositivo local que impeça o acesso de gravação a ele. (Pesquisa o hardware write blocker )

A parte importante é que a restrição tem que ser aplicada fora do conceito raiz dessa máquina. Um hacker criativo encontrará seu caminho em torno de todos os obstáculos que você colocar em dentro do ambiente que ele poderia controlar. Portanto, se o root puder alterar sua senha, o mesmo poderá ocorrer com sudoer .

Para ter certeza de que o usuário também não pode estragar suas habilidades de login, você deve ter montado somente leitura /bin e /sbin .

E você terá que ter um script que restaure periodicamente a conexão de rede.

(Como um sidenote: Se você permitir ao sudoer apenas um conjunto muito limitado de comandos e para cada um deles assegurar que eles não podem sair deles / substituí-los etc., então você pode evitá-lo enquanto possui /etc gravável ..)