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

66

Estamos com um pequeno problema em um servidor. Queremos que alguns usuários sejam capazes de, por exemplo, sudotornar-se root, mas com a restrição de que o usuário não pode alterar a senha root. Ou seja, uma garantia de que ainda podemos fazer login no servidor e nos tornarmos root, independentemente do que os outros usuários farão.

Isso é possível?

244an
fonte
32
Você pode usar sudopara conceder permissão apenas para aplicativos com privilégios de root específicos. Dessa forma, o usuário não poderá alterar a senha root
SHW
24
POR QUE você precisa sudodesses usuários. Se você não confia neles, não lhes dê sudoacesso em primeiro lugar. Observe também que, idealmente, o root não deve ter uma senha , mas você deve usar outros meios de autenticação. (O qual o usuário ainda poderá "hackear", mesmo se você proteger /etc/passwd)
Anony-Mousse 16/16/13
3
O que esses usuários precisam fazer exatamente?
Olivier Dulac
4
O que eles farão com seus privilégios de root? Pode haver uma solução melhor do que você está pensando.
Sparticvs
23
Este é um daqueles "Deus pode fazer uma pedra tão grande que ele próprio não pode erguê-la?" digite perguntas. Se você tiver acesso root, poderá fazer qualquer coisa, e é por isso que o acesso root é melhor concedido criteriosamente. sudoe setuidpode resolver a maioria dos problemas.
BSD

Respostas:

57

Queremos que alguns usuários sejam capazes de fazer, por exemplo, sudotornar-se root,

Bem, esse é o problema que o sudo foi projetado para resolver, para que essa parte seja fácil o suficiente.

mas com a restrição de que o usuário não pode alterar a senha root.

Você pode, como apontou o SHW em um comentário, configurar o sudo para permitir apenas que determinadas ações sejam executadas como raiz por determinados usuários. Ou seja, você pode permitir que o usuário1 faça sudo services apache2 restart, permita que o usuário2 faça, sudo rebootmas nada mais, enquanto permite que o contratado como administrador user3do sistema faça sudo -i. Existem instruções 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 foi concedida a capacidade de sudo -iou sudoem um shell ( sudo bashpor exemplo) pode fazer nada. Isso ocorre porque, no momento em que o sudo lança o shell, o próprio sudo está fora de cena. Ele fornece o contexto de segurança de um usuário diferente (na maioria das vezes root), mas não tem voz sobre o que o aplicativo executado faz. Se esse aplicativo for iniciado, passwd rootnão há nada que o sudo possa fazer a respeito. Observe que isso também pode ser feito por outros aplicativos; por exemplo, muitos dos editores mais avançados fornecem facilidades para executar um comando através do shell, um shell que será executado com o uid efetivo desse processo do editor (ou seja, root).

Ou seja, uma garantia de que ainda podemos fazer login no servidor e nos tornarmos root, independentemente do que os outros usuários farão.

Desculpa; se você realmente quer dizer "garantir que poderemos efetuar login e usar o sistema, independentemente do que alguém com acesso root faça", isso (para todos os efeitos) não pode ser feito. Um rápido "sudo rm / etc / passwd" ou "sudo chmod -x / bin / bash" (ou qualquer que seja a raiz do shell que use) e você estará praticamente hospedado de qualquer maneira. "Praticamente", que significa "você precisará restaurar do backup e torcer para que eles não tenham feito nada pior do que um deslize de dedos". Você pode tomar algumas medidas para reduzir o risco de um acidente acidental que leve a um sistema inutilizável, mas não pode impedir que a malícia cause problemas muito sérios, incluindo o ponto de precisar reconstruir o sistema do zero ou, pelo menos, do conhecido bons backups.

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

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

Se você não puder confiar neles com o nível de acesso que o root implica, precisará de uma configuração sudo muito mais rígida ou simplesmente não conceda ao usuário em questão acesso root de nenhuma maneira, sudo ou de outra forma.

um CVn
fonte
3
Sinto muito, minha resposta recebeu todo o hype (eu não entendi muito bem!). Sua resposta levanta excelentes pontos e espero que seja aceita. +1 para você, senhor.
Joseph R.
@JosephR. Às vezes, uma resposta concisa é preferida.
precisa
@DavidCowden Sim, parece que este é o caso aqui ...
Joseph R.
11
@JosephR. Não se preocupe comigo. A comunidade do Stack Exchange nem sempre é previsível, e as perguntas que já têm muitos votos positivos tendem a atrair mais. Obrigado pelo voto positivo, no entanto. :)
um CVn
92

Isso é praticamente impossível. Primeiro de tudo, se você lhes conceder o poder de se tornar raiz , não há nada que você possa fazer para impedi-los de fazer qualquer coisa. No seu caso de uso, sudodeve ser usado para conceder aos usuários alguns poderes de raiz e restringir outros sem permitir que eles se tornem root .

Em seu cenário, seria necessário restringir o acesso ao sue passwdcomandos e acesso aberto a praticamente tudo o resto. O problema é que não há nada que você possa fazer para impedir que seus usuários editem /etc/shadow(ou, /etc/sudoersnesse caso) diretamente e insiram uma senha raiz de substituição para seqüestrar a raiz. E este é apenas o cenário de "ataque" mais direto possível. Sudoers com energia irrestrita, com exceção de um ou dois comandos, podem contornar as restrições para seqüestrar o acesso root completo.

A única solução, conforme sugerido pelo SHW nos comentários, é usar sudopara 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 .k5loginarquivo.

Cito as partes relevantes:

Suponha que a usuária alice possuísse um arquivo .k5login em seu diretório pessoal, contendo a seguinte linha:
[email protected]
Isso permitiria que bob usasse aplicativos de rede Kerberos, como ssh (1), para acessar a conta de alice, usando tíquetes Kerberos de bob.
...
Observe que, como bob retém os tíquetes Kerberos para seu próprio diretor, [email protected]ele não teria nenhum dos privilégios que exigem tíquetes de alice, como acesso root a qualquer um dos hosts do site ou a capacidade de alterar a senha de alice.

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

Joseph R.
fonte
Como você fez essa referência legal a um comentário? Procurei na fonte a sua resposta e vi () ao seu redor. Chapéu secreto legal!
21413 Joe
@ Joe A hora em que um comentário foi postado é na verdade um link para o próprio comentário.
Joseph R.
@ Joe Encontre o ID ( <tr id="thisistheid"...) no comentário (por exemplo, no Chrome, clique com o botão direito do mouse e Inspect element) e , em seguida, acrescente-o ao link do tópico com um anterior #. No seu caso (id = comment-162798) se parece com isso: unix.stackexchange.com/questions/105346/...
polímer
11
Obrigado pela resposta, eu não sabia se deveria aceitar isso ou aquilo de @Michael Kjörling, eu escolhi o dele porque ele tem mais descrição - necessária para um noob como eu :) No entanto, o seu também foi útil
244an
@ 244an Não se preocupe. Eu mesmo recomendaria o mesmo. :)
Joseph R.
17

Suponho que você deseja garantir um acesso de "administrador de emergência", mesmo que o administrador atual estrague tudo (mas, além disso, você confia no administrador principal).

Uma abordagem popular (embora muito hackish) é ter um segundo usuáriouid=0 , comumente chamado toor(root backwards). Tem uma senha diferente e pode servir como acesso de backup. Para adicionar, você provavelmente precisará editar /etc/passwde /etc/shadow(copiar as rootlinhas).

É tudo menos à prova de falhas, mas se você precisar apenas se proteger contra o "administrador principal" alterando a senha sem aviso prévio, ela funcionará. É trivial desativar, removendo a toorconta; portanto, o único benefício é ter uma senha separada.

Como alternativa, convém procurar mecanismos de autenticação alternativos, como sshchaves libnss-extrausers, LDAP etc.

Observe que o administrador ainda pode estragar tudo. Por exemplo, bloqueando o firewall.

Se você deseja 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 refinada. Você pode conceder acesso root ao administrador, mas apenas uma função restrita (por exemplo, para administrar apenas o apache). Mas isso exigirá muito esforço do seu lado para configurar corretamente a política.

Anony-Mousse
fonte
6
Na verdade, isso não impede que o usuário tooraltere a senha root; Ele fornece apenas uma segunda senha para se tornar root.
Alexis
2
-1 então. Você está sugerindo uma senha de backdoor para que os administradores possam recuperar o acesso root depois de perdê-la ??? Isso é errado e, além dos usuários irritantes, pode desativá-lo facilmente, como você diz. Existem maneiras muito mais confiáveis ​​de configurar um backdoor.
Alexis19
2
@alexis É isso que IMHO, o autor da pergunta, pediu. Por que dar -1 para isso? toorcontas de recuperação tem sido uma prática comum (embora desaprovada) no Unix há décadas.
Anony-Mousse
9
Se o único objetivo é evitar alterações acidentais de senha, esta é uma boa resposta. Se o objetivo é impedir qualquer coisa maliciosa, isso não ajuda muito. Como o OP não disse qual era o objetivo, não sabemos.
22413 Bobson
2
Foi por isso que afirmei na minha primeira frase: "estraga tudo ... além disso, você confia ... totalmente". Esta é realmente apenas uma solução de "acesso de suporte"; não é um recurso de segurança. O uso de chaves root ssh adicionais alcança o mesmo, sem ser hackeado.
Anony-Mousse
11

A essência da raiz é ter um comando irrestrito do sistema. Você pode ajustá-lo com o SELinux (costumava haver um site de demonstração em que qualquer pessoa fazia 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 confiar nesses usuários para manter suas mãos afastadas da senha de root, eles não terão negócios como root. Se eles precisam administrar o servidor da web, vários dispositivos de hardware, a unidade warp ou qualquer outra coisa, configure uma solução para isso. Crie um grupo super poderoso, ofereça todo o acesso necessário e adicione-o. Se eles precisarem executar chamadas de sistema somente raiz, escreva alguns programas setuid.

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

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

alexis
fonte
Mas o problema é que você não pode impedir que o invasor ganhe raiz através de uma exploração, o SELinux fornece defesa em profundidade.
Timothy Leung
11

Provavelmente é possível, pelo menos em teoria, fazer isso usando o SELinux . Isso permite que você configure regras muito mais precisas sobre o que um usuário ou processo tem ou não permissão para fazer. Mesmo com o SELinux, pode ser complicado tornar impossível para um usuário alterar a senha de root, mas ainda ser 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 root realmente precisa fazer. Provavelmente seria mais fácil e seguro descobrir o que é isso e conceder essas permissões especificamente usando o sudo.

rjmunro
fonte
8
Embora fazer isso com o SELinux possa, em teoria, ser possível (e não estou convencido), afirmar que é sem mostrar regras reais não vai ajudar ninguém.
Gilles 'SO- stop be evil'
@ Gilles bem , na verdade , é para isso que o SELinux foi projetado. O SELinux é uma camada de permissões necessárias , além das permissões POSIX padrão. Em uma máquina SELinux configurada corretamente, o acesso raiz não faz sentido, pois suas permissões verdadeiras são determinadas pelo contexto de segurança e pela rotulagem de objetos.
tylerl
2
Se você souber como fazê-lo, responda Mito ou realidade: o SELinux pode limitar o usuário root?
Gilles 'SO- stop be evil'
Teoricamente, ainda pode ser possível com o SELinux; no entanto, a configuração de algo assim precisaria ser mais complexa, para garantir uma separação robusta entre TODOS os arquivos de configuração relacionados ao SELinux e o sistema de arquivos "normal" (ao qual o rootusuário tem acesso total). No final, o método "mais fácil" para essa separação (com ou sem SELinux) seria usar algo como o Kerberos, como mencionado por Joseph R.
ILMostro_7
7

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 permitir que você impedisse de efetuar login no host ou executar ações administrativas.

DSimon
fonte
Isso seria mais seguro do que muitas das opções IMHO.
Elder Geek
5

Não sei se será praticamente possível, mas aqui está um truque sujo:

  1. escreva um script / programa de wrapper que copie o /etc/passwdarquivo para outro local antes de chamar o arquivosudo
  2. Permitir que o usuário normal use sudo
  3. Depois que ele terminar sua tarefa ou quando ele sair do sudo, restaure o /etc/passwdarquivo

Eu sei, há muitas coisas mais-menos que você deve considerar para conseguir isso. Afinal, é um truque sujo

SHW
fonte
3
Sempre existe a possibilidade de um usuário mal-intencionado ler este script e remover a cópia de segurança.
Joseph R.
Isso também é basicamente o que os vipwamigos já fazem.
um CVn
Considere o programa e tenha apenas acesso root
SHW
11
rootpode editar o "outro local" depois sudo.
Anony-Mousse
5
Por que você concederia acesso root a um usuário potencialmente malicioso ??? Como root, é trivial instalar uma porta dos fundos que não dependa de passar pelo sudo e / ou pelo invólucro ...
alexis
5

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

Você usa visudopara modificar o arquivo sudoers. Aqui está um exemplo de linha:

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, no entanto.
  • = não precisa de explicação
  • ALL:ALLlê 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: diz para desativar o prompt de senha.
  • /path/to/command permite especificar comandos específicos path_to_commmand, another_command

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

Referências

  • da minha outra resposta aqui
RobotHumans
fonte
Esta resposta explica como configurar o sudo para acesso root limitado, mas seria muito melhor se a resposta dissesse isso e para onde deveria ir.
um CVn
@ MichaelKjörling done
RobotHumans
3
"A afirmação de que sudo é apenas para conceder root e não há proteção depois disso é descaradamente falsa". Digamos que eu conceda sudo viacesso a um usuário porque desejo que ele possa editar arquivos de configuração do sistema. Esse usuário faz :!/bin/bashdentro de uma sudo visessão. Como a capacidade do sudo de restringir quais comandos um usuário pode executar através do sudo ajuda a proteger meu sistema nessas circunstâncias? (Ninguém disse que o sudo não pode ser configurado com mais rigidez do que uma sudo -iabordagem do tipo tudo ou nada .)
um CVn
6
Compreender as limitações de uma abordagem é facilmente tão importante quanto saber como executar uma tarefa.
um CVn
11
@ MichaelKjörling, acho que este é apenas um exemplo. Mas, para ficar claro, a maneira correta de permitir que os usuários editem os arquivos de configuração do sistema é executá-los sudoedit. Você pode identificar especificamente quais arquivos eles devem poder sudoedit. Isto é, em man sudoers.
Matthew Flaschen
3

(Eu não conheço o ubuntu, mas deve ser semelhante ao Fedora / Red-Hat)
A única coisa que consigo imaginar restringindo o acesso à alteração da senha root não é fornecer acesso root completo, talvez com sudo, ou usando o SElinux para restringir o acesso para o arquivo de senhas ... mas eu não confiava com muito acesso, pois o root geralmente tem acesso irrestrito e poderia atualizar o SElinux, ou re-rotular o arquivo de senhas ou executar algum programa 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 a eles acesso root. Caso contrário, acho que você está tentando evitar acidentes.

Se você estiver apenas tentando proteger seu acesso ao root, configure um programa que possa restaurar a senha root, portanto, mesmo que tenha sido alterado, ele poderá ser restaurado com acesso mínimo. (sudo faz bem por si só)

9mjb
fonte
3

Sua exigência é:

Estamos com um pequeno problema em um servidor, [...] isto é, uma garantia de que ainda podemos fazer login nesse servidor e nos tornarmos root, independentemente do que os outros usuários farão.

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 travessuras de vez em quando (talvez estudantes?). Minhas sugestões abordam essa situação, não um ataque total de usuários mal-intencionados.

  1. Execute o servidor dentro de um ambiente virtual. Você poderá montar o sistema de arquivos do servidor e substituir os arquivos alterados por versões em bom estado. Dependendo do possível dano que você antecipar, 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 substituir os arquivos danificados, deixando o resto do sistema intacto.

  2. Execute o sistema somente leitura, por exemplo, a partir de um DVD-R. Se você puder viver com a maioria das partes do sistema estáticas até a próxima reinicialização, essa é uma boa opção. Você também pode usar um armazenamento de suporte somente leitura com um ambiente virtual ou carregar o sistema básico pela rede, facilitando muito as alterações entre as reinicializações do que gravar um novo DVD-R.

  3. Módulos do kernel. Os Linux Security Modules (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 pode ser configurada imediatamente para impedir o acesso de gravação a / etc / passwd, / etc / shadow ou qualquer outro arquivo que você deseja, mesmo pela raiz.

  4. A mesma idéia que o nº 1, mas quando o servidor não está em um ambiente virtual. Você pode carregar o servidor em cadeia em um sistema operacional somente leitura, como um CD ao vivo, que monta automaticamente o sistema de arquivos do servidor e sobrescreve o sistema básico em cada inicialização com cópias em boas condições. O sistema operacional somente leitura seria inicializado no sistema operacional principal.

  5. Novamente, supondo que sejam usuários semi-confiáveis ​​e responsáveis ​​perante um superior (professor / chefe), a melhor resposta pode ser a Auditoria do Linux . Dessa forma, você saberá todas as ações relevantes à segurança executadas e quem as executou (você saberá quem as executou, porque, mesmo que todos os usuários compartilhem a conta raiz, eles terão processado sua conta de usuário primeiro). Na verdade, você pode até analisar o log de auditoria em tempo real e substituir arquivos danificados. / etc / shadow substituído? Não tem problema, basta fazer com que o servidor de monitoramento o substitua instantaneamente por uma versão em bom estado.

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

Animismo
fonte
2

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

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

Darren Cook
fonte
2
Não. Como Michael observou tão apropriadamente , um usuário mal-intencionado pode impedir o acesso root sem necessariamente seqüestrar a senha simplesmente desarrumando os binários. Mesmo a init=...abordagem pode ser impedida de remover permissões de execução de binários pertinentes. Eu acho que uma solução melhor nesse caso, é montar seu sistema de arquivos raiz via LiveCD e (tentar) corrigir o dano. Então, novamente, se você acredita que o sistema foi comprometido, é melhor restaurar do backup de qualquer maneira.
Joseph R.
Concordou @JosephR; descobrir e corrigir danos é complicado, e eu também reinstalaria. Mas acho que a preocupação do OP era mais sobre alguém acidentalmente os prender ... invadir deliberadamente uma situação de trabalho ou escola é um pouco suicida. ;-)
Darren Cook
11
Não necessariamente. Um usuário verdadeiramente mal-intencionado, combinado com um administrador de sistema descuidado / sem noção, pode escalar privilégios sem ser detectado. Concordo que a intenção original do OP era provavelmente evitar erros inocentes, em vez de nos proteger contra intenções maliciosas, mas a pergunta foi marcada como "segurança" e nós continuamos com ela, eu acho :) :)
Joseph R.
2

Se você clonar seu servidor em uma VM (como o VirtualBox ), poderá conceder acesso root irrestrito às pessoas e ainda garantir que sempre terá acesso direto às partições do sistema operacional convidado e, portanto, manterá o controle final sobre /etc/passwde do mesmo jeito, já que você terá root no sistema host.

Obviamente, conceder acesso root irrestrito ainda pode não ser a solução certa: se a segurança dos dados é um problema ou sua responsabilidade, você não pode dar acesso root.

SevenSidedDie
fonte
2

O requisito não é tecnicamente possível. Como já foi eloquentemente comentado, conceder sudodireitos ilimitados ou até mais limitados a um usuário significa que você confia nesse usuário. Alguém com más intenções, capacidade técnica e perseverança suficientes pode passar por quaisquer obstáculos que sejam colocados no lugar.

No entanto, supondo que você possa confiar que seus usuários não sejam mal intencionados, você pode fazer com que a restrição de alteração de senha seja uma questão de política . Você pode criar um wrapper para o passwdprograma que os lembrará "por favor não altere a senha root". Isso pressupõe que a origem do problema é que os usuários que estão alterando a senha root estão fazendo isso devido a um mal-entendido (como talvez pensando que estão alterando sua própria senha depois de ter feito sudo bash).

Em circunstâncias especiais (raras), se a confiança completa não for possível e não for possível interromper o sudoacesso a blocos adequados, mas razoavelmente seguros, considere o estabelecimento de sanções organizacionais contra a alteração de senha (ou qualquer outra forma especificada de violação do sistema), organize monitoramento de recursos críticos para que não seja fácil passar despercebido para contornar as políticas definidas - e ser público e transparente sobre as regras e o monitoramento de uso.

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

  1. detectar quando um usuário altera a identidade para root e acompanhar qualquer processo criado;
  2. registre as criações do processo a partir de então para ver quem é o usuário original responsável por cada processo e usando o host remoto onde os usuários semi-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, posteriormente, descobrir quem estava por trás da violação da política.

Pelo menos, precisaríamos registrar a abertura de um conjunto de arquivos que não seja seguro para gravação, criação de processos exec()e, claro, qualquer tentativa de alterar a rede.

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

Obviamente, é impossível fazer com que esse rastreamento e log funcionem 100% corretamente, não é fácil de implementar e também requer recursos adicionais para operar. Isso não impediria a alteração da senha ou outras violações indesejadas do sistema, mas tornaria (mais provável) possível encontrar o usuário culpado ou, pelo menos, criar uma ilusão de que há monitoramento e torná-lo menos convidativo para alguns usuários mal-intencionados (mas alguns hackers que amam problemas e que veem a futilidade fundamental das medidas técnicas implementadas podem se sentir incentivados a aceitar o desafio e tentar contornar o sistema apenas por diversão).

FooF
fonte
1

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

O problema é: se o proprietário tiver acesso físico à caixa, ele poderá recuperar facilmente os acessos lógicos ao sistema (desde que ainda esteja ativo :). Caso contrário, manter a senha root não será resgatada, por exemplo, de configuração sshd inativa ou de redes ruins, portanto o sistema ainda não estará acessível.

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

Falando sobre emergência remota, entre na solução, a melhor maneira é IPMI (eu acho) se estiver disponível. O proprietário do sistema pode anexar a unidade virtual a qualquer momento, inicializá-la e prosseguir com a recuperação do sistema.

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

Veniamin
fonte
0

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

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

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

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

O segundo valor (ALL) define a que hosts essa regra do sudo se aplica. Esta coluna é mais útil quando você implanta um ambiente sudo em vários sistemas. Para um sistema Ubuntu de desktop, ou um sistema em que você não planeja implantar as funções sudo em vários sistemas, fique à vontade para deixar esse valor definido como ALL, que é um curinga que corresponde a todos os hosts.

O terceiro valor é definido entre parênteses e define como ou quais usuários o usuário na primeira coluna pode executar um comando como. Este valor é definido como root, o que significa que jorge poderá executar os comandos especificados na última coluna como usuário root. Esse valor também pode ser definido como o curinga ALL, o que permitiria ao jorge executar os comandos como qualquer usuário no sistema.

O último valor (/ usr / bin / find, / bin / rm) é uma lista de comandos separados por vírgula que o usuário na primeira coluna pode executar como usuário (s) na terceira coluna. Nesse caso, estamos permitindo que o jorge execute find e rm como root. Esse valor também pode ser definido como o curinga ALL, o que permitiria ao jorge executar 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 não adicione passwdisso, deve ficar bem

ehime
fonte
-1

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

Se você quiser ter um mecanismo à prova de falhas para efetuar login no servidor como root, poderá criar outro usuário uid=0ou criar um cron simples que redefinirá a senha root periodicamente.

Martin
fonte
É fácil de escapar da festa restrita, consulte este Sans blogue
Franklin Piat
-1

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

su -

tornar-se raiz. A raiz uid = 0; uid da roda = 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 roda. (Se você usa o wheel, não cometa o erro de adicionar root como membro do grupo do wheel). Dê uma olhada na documentação da Red Hat se você não souber o que é 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 / allowedkeys, isso evita qualquer preocupação com a alteração da senha root, porque a senha 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 o bit Imutável. Depois de criar o arquivo ~ / .ssh / allowedkeys e depois de configurar o / etc / ssh / sshd_config e / etc / ssh / ssh_config como desejar, defina o bit Imutável. Claro, existem maneiras de estragar tudo também - nada é perfeito.

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

Todas as respostas enviadas, incluindo as minhas, falham ao tratar do acesso físico. Quem quer que tenha, tem controle. Se não for você, provavelmente haverá uma maneira de fazer com que a pessoa que acessa fisicamente a máquina, caso alguém encontre uma maneira de impedir que você faça o login ou se encontrar uma maneira de fazer o login, mesmo depois de você tentei impedir que isso acontecesse. Obviamente, se você tiver acesso físico, poderá não haver necessidade de alguma dessas coisas, embora a implementação de algumas deva ser considerada de qualquer maneira, se você estiver interessado em NÃO ser incomodado.

-John Crout

John Crout
fonte
sudoé imensamente diferente de su -. Isso tem sido apontado repetidamente, por exemplo, por SHW , Joseph R. , eu mesmo , hbdgaf e muito mais, o campo de comentários é muito curto para incluir ...
a CVn
Tudo verdade, mas irrelevante. Você está discutindo maneiras alternativas de se tornar root e os riscos de conceder acesso root, mas nada que tenha relação com o "acesso root que não pode alterar a senha root".
Gilles 'SO- stop be evil'
Verdadeiro. A questão é um oxímoro lógico; Não pode existir a menos que a instalação esteja com problemas. Qual a vantagem de um login / conta de usuário em que esse usuário não pode alterar sua senha e ainda assim ter acesso root? Portanto, as sugestões oferecidas se aplicam ao que o questionador pode ter significado; não da maneira como eles escreveram a pergunta. Qualquer método de controle de acesso possui riscos inerentes.
John Crout
-3

Uma maneira seria garantir que isso /etcnão seja gravável. Por ninguém, contanto que pudesse haver uma sudoervolta.

Isso pode ser feito montando-o na rede e garantindo, por outro lado, que o dispositivo não possa ser gravado.

Isso pode ser feito usando um dispositivo local que impede o acesso de gravação a ele. (Pesquise o write blockerhardware)

A parte importante é que a restrição deve ser aplicada fora do conceito raiz dessa máquina. Um hacker criativo encontrará seu caminho para contornar todos os obstáculos que você colocar nele dentro do ambiente que ele poderia controlar. Portanto, se o root pode alterar sua senha, o mesmo acontece com a sudoer.

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

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

(Como uma nota de rodapé: se você permitir ao sudoer apenas um conjunto muito limitado de comandos e, para cada um deles, garantir que eles não podem romper com eles / substituí-los etc., será possível evitá-lo enquanto tiver /etcgravável ..)

Angelo Fuchs
fonte
A montagem do / etc somente leitura, embora talvez seja possível (você teria que ter cuidado durante a raiz dinâmica nos scripts de inicialização do initrd, por exemplo), corre o risco de ser uma configuração bastante frágil. Além disso, há muitas coisas que um usuário com acesso root pode fazer, o que prejudica a capacidade de outros usuários de obter privilégios de root, que não envolvem modificações no / etc.
um CVn
@ MichaelKjörling A instalação não é frágil, eu a uso frequentemente (como montagens locais somente leitura).
Angelo Fuchs
@ MichaelKjörling Adicionei alguns outros elementos que você deseja ter somente leitura, se quiser garantir que ainda pode fazer login. Portanto, a lista de ações que devem ser executadas se você seguir esse caminho não é tão curta, mas é a única maneira de "garantir que ainda podemos fazer login no servidor e nos tornarmos root, independentemente do que os outros usuários farão".
Angelo Fuchs
Admito que nunca vi a necessidade de experimentá-lo, mas uma coisa que definitivamente posso ver que seria arriscada é como o init vai lidar com o / etc / inittab sendo substituído sob seus pés. Ou o que o sistema fará se o / etc / fstab inicial e após a remontagem forem diferentes. E há / etc / mtab. Outros usuários podem querer alterar suas próprias senhas, o que envolve escrever em / etc / shadow e possivelmente em / etc / passwd. E montar / etc somente leitura ainda é apenas uma solução parcial. Não estou dizendo que não possa fazer parte de uma solução, mas certamente não é o primeiro passo que daria na situação do OP.
um CVn
11
Sim. Fazer isso é perigoso e tem problemas graves se for feito errado. Mesmo assim, até onde eu vejo, é a única maneira viável de resolver a solicitação de OPs para usuários que devem ter permissão para se tornarem root.
Angelo Fuchs