Posso criar um superusuário super para que eu possa realmente ter um usuário que possa negar permissão de root?

34

Eu estava pensando que poderia ser vantajoso ter um usuário com permissões maiores que o usuário root.

Veja bem, gostaria de manter todas as atividades e quase todos os privilégios de usuário root existentes exatamente como são agora.

No entanto, eu gostaria da capacidade de negar privilégios de root em uma base extremamente isolada caso a caso.

Uma das vantagens disso me permitiria impedir a instalação de certos arquivos indesejados durante as atualizações. Este é apenas um exemplo de uma possível vantagem.

Como as atualizações do apt-get são executadas pelo root ou com privilégios de sudo, o apt-get pode substituir certos arquivos indesejados durante as atualizações.

Se eu pudesse negar esses privilégios a esses arquivos particulares individuais, poderia defini-los como um simlink para /dev/nullou possivelmente ter um arquivo de espaço reservado em branco que pudesse ter permissões que impediriam que o arquivo fosse substituído durante a atualização.

Além disso, não posso deixar de me lembrar de uma frase que foi dita em uma entrevista com um dos criadores do Ubuntu quando o cara disse algo sobre como os usuários confiam melhor em "nós" (referindo-se aos desenvolvedores do Ubuntu) "porque temos root "que era uma referência a como as atualizações do sistema são executadas com permissão root.

Simplesmente alterar o procedimento de instalação para dizer que contornar esse problema não é absolutamente o que estou interessado aqui. Agora que minha mente gosta da idéia de ter o poder de negar o acesso root, gostaria de descobrir uma maneira de fazer isso acontecer apenas por fazê-lo.

Eu apenas pensei sobre isso e não gastei nenhum tempo com a idéia até agora e estou bastante confiante de que isso poderia ser descoberto. No entanto, estou curioso para saber se isso já foi feito ou se isso possivelmente não é uma idéia ou conceito novo.

Basicamente, parece que deve haver alguma maneira de ter um superusuário super que tenha permissão além da do sistema em apenas um grau.


Nota: Embora eu ache que a resposta aceita se encaixa mais nos critérios, eu realmente gosto da resposta do @CR. Além disso.

Eu gostaria de criar um usuário real mais alto na árvore (eu), mas acho que vou ter que me sentar um dia quando tiver tempo para descobrir isso.

Além disso, não estou tentando escolher o Ubuntu aqui; Eu não o usaria como minha distro principal se me sentisse negativo.

mchid
fonte
4
De que tipo de arquivos você está falando e por quê? " impedir que certos arquivos indesejados sejam instalados _" sugere que os arquivos (normalmente) não existem, e você deseja impedi-los; mas "_que negaria que o arquivo fosse substituído durante a atualização. " sugere que os arquivos já existem (com conteúdo presumivelmente desejável) e você não deseja novas versões.
TripeHound
6
Esteja ciente de que qualquer método que impeça apta gravação excessiva de arquivos pode levar a um erro, interrompendo o processo de atualização. aptrecusará fazer atualizações ou instalações até que o "problema" seja resolvido.
Dubu
6
"Simplesmente alterar o procedimento de instalação para dizer que contornar esse problema não é absolutamente o que estou interessado aqui." Talvez sim, mas geralmente é a maneira correta de resolver o problema, conforme indicado. A limitação da raiz pode ser feita (formalmente, a raiz no usuário não é o mesmo nível de acesso que o modo kernel), e existem sistemas para realizá-la, mas isso contraria a filosofia do Unix e os princípios básicos de segurança. Em geral, uma vez que alguém tenha raiz "parcial", é excepcionalmente difícil colocar na lista negra tudo o que eles podem usar para obter raiz "completa". Prefira apenas dar raiz ao código confiável.
Kevin
8
@mchid: root é o controle total. Esse é o objetivo. Para que ele não tenha controle total, você precisa negar tantas coisas que não se parecem mais com o root (por exemplo, não instala módulos do kernel, não instala dispositivos arbitrários e assim por diante). Se você não deseja executar as coisas como root, não as execute como root. Em vez disso, distribua recursos (exceto todos os equivalentes a raiz , não se preocupe com eles) ou execute um daemon como o polkitd, que executa operações raiz em nome de processos não raiz.
Kevin
4
@mchid: Esse é o problema: existem várias maneiras de os programas contornarem suas restrições. A menos que você faça uma lista negra de todas essas formas, qualquer programa executado como "raiz restrita" ainda poderá se tornar raiz total sempre que desejar. Portanto, todo o seu esquema não passa de uma charada de teatro de segurança.
Kevin

Respostas:

83

O "usuário" desejado é chamado LSM: Linux security module. Os mais conhecidos são o SELinux e o AppArmor.

Com isso, você pode impedir que certos binários (e seus processos filhos) façam certas coisas (mesmo que o UID deles seja root). Mas você pode permitir que essas operações gettye seus processos filhos sejam executados manualmente.

Hauke ​​Laging
fonte
2
Mas se o UID deles é root, eles não podem alterar as permissões selinux que os impedem de acessar?
Curious_cat
11
@curious_cat: Sim, é claro que você precisa negar a um processo de "raiz limitada" a capacidade de alterar / aumentar sua própria permissão! As pessoas que escreveu SELinux pensado que já ...
Peter Cordes
8
@curious_cat Você pode configurar os LSMs para que seja completamente impossível alterar sua configuração em tempo de execução. Você precisa reiniciar e fornecer um parâmetro do kernel para isso.
Hauke ​​Laging
5
@ Josué Se a sua cópia do apt-get estiver usando o Rowhammer, você terá problemas maiores com que se preocupar.
Draconis
3
@corsiKa Primeiro, você deseja restringir as pessoas que podem inicializar a máquina às pessoas que realmente estão na máquina, porque os sistemas são vulneráveis ​​durante a inicialização. Disparar uma reinicialização pela rede é bom, mas permitir o controle durante a inicialização não é. Segundo, uma regra de segurança do computador é que você não pode fazer nada depois que um invasor tiver acesso físico, pois, assim, ele pode enterrar tudo no LN2 / reconectar o hardware / etc. Portanto, sim, geralmente se supõe que alguém que possa alterar a inicialização de uma máquina tenha "vencido" a máquina.
HTNW 5/09/17
51

Você está entendendo mal o conceito de rootusuário.

Em inglês simples, rootestá no "topo da árvore".

E se você decidir um dia ter um "super super usuário" e, no próximo mês, um "super super super usuário" (!). Quão longe "a árvore" você gostaria de ir? Como você embaralha todas as permissões e hierarquia para fazer isso funcionar? Quem está sempre no topo? Alguém tem que estar no topo, e está root. Fim da história.

As soluções fornecidas aqui - incluindo AppArmor e SELinux - realmente não mudam isso. Eles simplesmente permitem um controle mais refinado das rootpermissões e processos.

Parece-me que seu processo de atualização não é adequado para o resultado desejado. Mas isso não é culpa do rootusuário. Em vez de complicar rootdemais as coisas, pense no usuário de permissão de nível mais alto e, em seguida, em todo o resto, você precisa trabalhar para baixo.

Sei que algumas pessoas marcarão isso, mas não há nível mais alto na hierarquia de usuários, e todas as outras soluções simplesmente dão um controle ligeiramente diferente de como as rootpermissões funcionam. Mas eles não criam um novo usuário, com permissões mais altas.

Você não pode ter um usuário com "mais permissões" do que rootporque rootrepresenta o nível mais alto possível de permissões. Usar uma frase como "mais controle que raiz" é uma contradição - roottem controle total e todas as permissões possíveis, portanto não há nada que possa ser feito acima dela.

Andy
fonte
Eu estaria no topo, não na raiz, no final da história. Como não há um nível mais alto na hierarquia do usuário, é exatamente o motivo pelo qual gostaria de criar um usuário mais alto.
Mchid 06/09/19
Embora isso seja o que eu quero: controle sobre permissões e processos raiz, para que eu possa negar permissão para fazer root. Se, de alguma forma, posso negar permissão para fazer root sem criar um novo usuário com o SELinux ou o AppArmor, acho que não preciso de um novo usuário. Eu quero controle total, mais controle que raiz.
Mchid 6/09/17
16
Você não pode ter um usuário que tenha "mais permissões" do que root. Esse é o problema todo. O usuário que você deseja criar é essencialmente o usuário raiz. Você precisa abordar isso de outra maneira, como criar um usuário com rootprivilégios e depois negar alguns onde deseja um controle mais refinado. O que você está perguntando ("mais controle do que root") não é possível, ou até mesmo uma coisa!
Andy Andy
@mchid Então, o que você realmente quer fazer é renomear o usuário root atual para mchid, criar um novo usuário chamado root e fazer com que o apt-get et al use seu novo usuário não root?
Odalrick
Em alguns sistemas, rootnão tem permissão para acessar o hardware diretamente. Se você desativar o carregamento dos módulos do kernel, poderá manter o root fora do controle total do hardware ( /dev/meme coisas assim). Não é realmente relevante para as permissões do sistema de arquivos, pois você não usaria um apt-get que falasse diretamente com o seu controlador SATA ou NVMe ... Mas tecnicamente, há um estado "mais permissões que root" e é chamado de modo kernel. : P
Peter Cordes
26

Se você apenas deseja impedir que arquivos ou diretórios sejam alterados / excluídos, basta definir o sinalizador imutável neles.

chattr +i <file>

Nem mesmo o root poderá fazer nada a menos que o sinalizador seja removido. Também é possível usar o sistema de contêiner / espaço para nome para impedir o acesso root, mas isso parece um exagero para o que você precisa.

CR.
fonte
11
Mas o root pode remover a bandeira.
setbas
10
O apt, como quase tudo, não usará o chattr para remover essa bandeira.
CR.
13
@sebasth: Correto, mas os scripts de instalação do Apt, dpkg e por pacote (normalmente) não alteram os atributos do arquivo. Em vez disso, eles simplesmente falham e reclamam quando tentam alterar arquivos com o sinalizador imutável.
David Foerster
4
@TripeHound Então, o OP deseja apt-getsubstituir o arquivo, mantendo-o intacto? Isso é algo contraditório, ouso dizer.
Dmitry Grigoryev
3
@DmitryGrigoryev Ele soa como eles querem apt-getpara pensar que sucedeu, mas deixando um ou mais arquivos inalterada. Eles não dizem quais arquivos ou por quê, mas, como você diz, um tanto contraditórios - e propensos a "comportamentos estranhos" no futuro.
TripeHound 4/17/17
9
  • Em vez de ter um superusuário, você pode limitar o root. veja Quais são as diferentes maneiras de definir permissões de arquivo, etc. no gnu / linux

  • Há também o AppArmor e o SELinux.

  • E / ou configure sudo, para que você não conceda privilégios de root completo. Você pode configurá-lo para que um usuário possa executar apenas comandos pré-acordados, com argumentos pré-acordados.

  • Você também pode usar a virtualização para restringir a raiz:

    • cgroups, namespaces, chroot etc. (o docker faz isso)
    • Xen
    • Virtualbox
  • Veja também etckeeper: esta revisão da ferramenta controla o /etcdiretório e sincroniza com o apt. Por padrão, não é seguro, uma instalação mal-intencionada pode sabotá-la, mas você também pode fazer com que ela faça alterações em um repositório de backup com barreira contra incêndio.

  • Uso do controle de revisão em geral, com um repositório de backup em paredes de incêndio. Isso ajuda com corrupção acidental e intencional e falha de hardware.


Os repositórios de backup com firewall podem estar em uma máquina diferente, na Internet ou em uma máquina virtual diferente (ou host da máquina virtual).

ctrl-alt-delor
fonte
8

Para softwares como o APT , que em operação normal exigem acesso a quase todo o sistema, a restrição é problemática. Mesmo que você impeça o acesso a certas partes do sistema, é muito provável que existam possibilidades mais do que suficientes para que um distribuidor mal-intencionado trabalhe. Por exemplo, substituindo uma biblioteca ou apenas um binário ou adicionando uma alteração de configuração maliciosa, que a raiz irrestrita será usada eventualmente.

Dependendo de quanto você colocaria restrições, é esperado que alguns scripts de instalação sejam quebrados.

Para maneiras de restringir aplicativos e usuários, você pode escrever uma política do AppArmor ou SELinux. Essa política dependerá da sua distribuição: o Debian tem melhor suporte para o AppArmor, enquanto as distribuições baseadas no Fedora / RHEL habilitam o SELinux por padrão.

O AppArmor e o SELinux trabalham em políticas de lista branca , que contêm regras para permitir (ou negar) ações específicas. As políticas são aplicadas a um processo no exec , da mesma forma que os usuários podem ser restringidos quando uma política é aplicada a seus processos no logon. Uma política bem pensada não pode ser contornada (se os erros do kernel não forem considerados). Processo confinado em execução como raiz (uid 0) é restrito pela política configurada e não pode alterá-lo, a menos que seja explicitamente permitido na política.

A linguagem da política do AppArmor define uma regra de negação , que pode ser usada para criar uma política da lista negra . Um bom lugar para começar com o AppArmor é as páginas de manual do AppArmor , o wiki do e a visualização da configuração existente em sua distribuição /etc/apparmor.d/.

Muitos materiais de administração e desenvolvimento do SELinux são fornecidos no wiki do SELinux . A política de referência do SELinux está hospedada no github.

sebasth
fonte
7

Eu não posso acreditar que ninguém mencionou a possibilidade de fixar ...

Há alguns anos, a Microsoft lançou um patch que impedia as máquinas Windows 10 de conversar com nossos antigos controladores de domínio Samba NT4. Quando o problema foi encontrado, fixamos o pacote Samba para permanecer na versão atual e aptainda funcionamos corretamente.

Um passo a passo completo do Debian a explica bem o processo:

Em /etc/apt/preferences(ou um novo arquivo abaixo /etc/apt/preferences.d/), adicione algum texto para especificar qual pacote e versão:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Verifique a documentação para a sintaxe exata, mas esta é a maneira rápida e suja em que fixamos uma versão do pacote. Raiz poderia ignorá-lo, como o root sempre pode fazer, mas isso resolve o problema dos gerenciadores de pacotes que tentam atualizar automaticamente os pacotes em você.

NOTA: Esta resposta está assumindo que você tem um problema XY

O canadense Luke REINSTATE MONICA
fonte
Eu já respondi vários problemas XY no askubuntu. No entanto, o apt é apenas um exemplo e é o que me leva à ideia. Estou mais interessado no aspecto "o poder corrompe e o poder absoluto corrompe absolutamente" a coisa toda. Poder total e absoluto sobre o meu próprio sistema é o que me levou ao Linux em primeiro lugar. Perceber que meu poder nem sempre é absoluto sobre a raiz é meio perturbador; a idéia de poder absoluto é atraente.
mchid 6/09/17
Além disso, acho que é um problema XY, mas Y aqui é "como nego permissão para fazer root quando root é o superusuário?"
Mchid 6/09/17
11
@mchid não se trata de negar permissões para o root, mas negar algo a um programa em execução como root.
John Keates
6

Na verdade, é bastante simples.

Raiz é o seu "super super usuário"

Crie uma conta chamada "admin" e dê a ele todas as permissões de root, exceto as que você não deseja.

Em seguida, crie um usuário chamado bob e deixe-o "se tornar administrador". Usando su ou mesmo sudo.

Agora você tem um usuário normal (bob), um superusuário que pode fazer coisas administrativas (admin) e um superusuário super (root).

Se você quiser alterar o nome "root" para outra coisa, você pode fazer isso. Tecnicamente, apenas o ID do usuário (0) é importante.

coteyr
fonte
Se eu tivesse um usuário normal (bob), um superusuário que possa fazer coisas administrativas (admin) e um superusuário super (raiz), o root ainda não estaria fazendo todas as coisas administrativas com os processos em segundo plano, cronjobs e outras coisas como identificação do usuário (0)?
Mchid 6/09/17
não se você não quiser. A maioria dos serviços permite escolher qual usuário faz o trabalho. Você pode configurá-lo para que o usuário administrador seja o responsável pelos processos. Existem algumas exceções, mas não muitas.
coteyr
Não precisaria passar e definir todos esses processos individualmente?
Mchid 6/09/17
3
É o que acontece quando você tenta quebrar as convenções padrão. Eu acho que você precisa entender melhor como e por que os sistemas de permissões em um ambiente * nix.
Shauna
2
Concordo com Shauna, você parece não ter um entendimento fundamental do sistema de permissão * nix. É muito poderoso, mas não é nada como janelas.
coteyr 6/09/17
3

Se o que você deseja é simplesmente impedir que arquivos específicos sejam instalados, restringir as permissões de root não é o caminho a seguir. Vale ressaltar também que as respostas convencionais (arquivos imutáveis ​​ou LSMs) não funcionarão para o seu caso de uso específico, pois o APT (e a maioria dos outros gerenciadores de pacotes) será resgatado se não puderem instalar arquivos.

A verdadeira pergunta que você deseja fazer é:

Existe uma maneira de impedir que o APT instale arquivos específicos?

Isso é algo completamente diferente do que você está perguntando em vários níveis.

Agora, quanto a essa pergunta, eu não tenho 100% de certeza, mas sei que vários outros gerenciadores de pacotes têm opções para impedir a instalação de arquivos específicos (por exemplo, o sistema Portage do Gentoo tem a opção INSTALL_MASK=, que realmente aceita shell padrões de estilo de coisas a serem instaladas). Eu estaria mais do que disposto a apostar que essa opção existe para o APT (ou possivelmente o próprio dpkg).

Austin Hemmelgarn
fonte
Realmente, "Existe uma maneira de impedir que o APT instale arquivos específicos?" não é minha pergunta; este é apenas um exemplo e o que trouxe a pergunta à minha mente. O novo firefox é fornecido com complementos e instala esses arquivos mesmo depois que o usuário os exclui com novas atualizações. Este não é realmente o problema; Foi isso que me fez perceber que quero ainda mais controle sobre o meu sistema. Aprecio, no entanto, sua lógica aqui, pois respondi algumas perguntas dessa maneira, portanto, obrigado pela contribuição.
Mchid 6/09/17
O dpkg-desvio faz isso: unix.stackexchange.com/a/157896/70847
mchid 6/17
1

Coloque uma cópia de segurança em um local seguro. Após qualquer instalação / atualização, substitua imediatamente os arquivos específicos desse backup. Portanto, não há erros para estragar a instalação, mas você ainda recupera os arquivos que deseja manter.

WGroleau
fonte
1

Trabalhar a partir de uma unidade montada

Observe que essa é principalmente uma resposta conceitual, mas acho que deve funcionar e estar em espírito com o que você deseja alcançar.

Deixe o sistema X ser seu sistema de trabalho e o sistema Y um outro sistema que você controla

  1. Monte um diretório a partir de Y como uma unidade no X
  2. Configure os direitos de forma que o usuário root do X tenha direitos sobre tudo nesta unidade montada, com algumas exceções

Agora você tem sua 'raiz de trabalho', que pode fazer quase tudo, e sua 'super raiz', a conta raiz real do sistema Y, que pode realmente fazer tudo.

Dennis Jaheruddin
fonte
Eu gosto da ideia, porém, gostaria de fazer isso em um sistema em execução.
mchid 6/09/17
1

Você pode executar um hipervisor tipo 1 como o hipervisor Xen e hospedar seu sistema operacional normal como convidado virtualizado. O hipervisor controla o SO convidado virtual em um nível "mais profundo" que o root, porque ele tem controle sobre o hardware (virtual) no qual o SO convidado é executado.

Você pode programar o hypervisor para manipular o SO convidado de várias maneiras, incluindo alterar permissões, criar e aplicar backups, conectar determinadas alterações ou instruções no SO convidado para injetar funcionalidade, validação, etc. adicionais. Essa seria uma maneira válida e potencialmente útil implementar um sistema do tipo unix com um "usuário" (na verdade uma função do hypervisor) para "fazer coisas que nem o root pode fazer"

Meu senso de que essa abordagem provavelmente é um exagero

Nathan Smith
fonte
Como um hipervisor impede que um usuário com permissão root faça o que ele deseja fazer em uma VM convidada?
fpmurphy
Esta resposta começa bem, mas depois se perde gramaticalmente (é então ler errado, ou pelo menos ambigüidades). Eu fiz uma correção.
Ctrl-alt-delor
11
@ fpmurphy1 um hipervisor pode conectar chamadas do sistema, aplicar políticas etc. para impor restrições arbitrárias ao usuário root ou a qualquer outra parte do sistema operacional convidado. Talvez a minha resposta não é bom porque esta é a maneira muito trabalho a menos que você tem algum caso de uso real, empresa ou algo embora ...
Nathan Smith
@ ctrl-alt-delor Obrigado pela correção, mas acho que a gramática não foi o problema. Eu esclareci o que eu quis dizer, porém, e eu aprecio o feedback que os meus pensamentos não eram claros no início
Nathan Smith
11
@ fpmurphy1 dentro do convidado, você tem raiz completa. No entanto, não é a mesma raiz que a raiz no host. Portanto, é uma raiz menor que a raiz do host. O Docker permitirá que as coisas sejam mais integradas, mas ainda impõe restrições à raiz.
CTRL-ALT-DELOR
1

Dê uma olhada nos namespaces do cgroups e Linux como um método alternativo para atingir esse tipo de objetivo, bem como ferramentas baseadas neles, como Docker e lxd .

Essas ferramentas permitem, entre outras coisas, limitar quais partes do sistema de arquivos um processo em execução como "raiz" pode ver, limitar quais processos são visíveis a ele e fornecer apenas certos recursos ao usuário "raiz".

smw
fonte
0

DESINSTALAR sudo

Que tal desinstalar sudoe link simbólico /bin/supara /bin/false? Junte isso para garantir que rootnão é possível acessar via sshe você bloqueou o sistema.

Isso torna rooto Super * Super Usuário, e todo mundo está subordinado a isso.

Para arquivos substituídos durante as atualizações, simplesmente não faça nenhuma atualização. Mais realisticamente, alterar as permissões dos arquivos para 440ou 444de modo que não pode ser escrito. Ou coloque-os em um repositório git para que, se eles forem substituídos, possam ser revertidos.

user176717
fonte
Veja bem, ainda quero fazer atualizações e ainda quero que o root faça praticamente tudo o que o root normalmente faz. No entanto, eu quero poder dizer que torce "ei, não faça isso" ou "não, você não pode fazer isso", como uma autoridade parental seria capaz de fazer com uma prole. Como é agora, Root é como a autoridade dos pais no meu sistema e todas as crianças dizem "mãe, posso?" quando eles usam sudo. Isto é bom. No entanto, quase todas as pessoas neste planeta são descendentes de alguém. Parece que algumas respostas estão aqui como uma criança estaria em antes de auto-consciência, quando eles não percebem
mchid
. . . que vovó e vovô são mães e pais de mamãe e papai. Eu gostaria de perguntar avô para vir morar no meu sistema, porque, agora, a raiz é o pai da casa e vovô pode dizer papai o que fazer porque vovô é o pai de Papai :)
mchid
Parece que você adicionou muitas pessoas com poderes sudo. Ajuste o sudoersarquivo para que apenas usuários selecionados possam executar comandos pré-selecionados.
User176717
Eu tenho apenas dois usuários no arquivo sudoers, incluindo root. Eu estava tentando usar um símile para explicar como algumas pessoas parecem não entender minha pergunta e o que eu gostaria de alcançar.
Mchid 9/09/2017
Parece que as pessoas sentem que não pode haver um usuário acima da raiz da mesma maneira que uma criança muito jovem sente que seus pais não podem ter pai ou mãe. Além disso, eu não votei.
Mchid 9/09/2017