Eu estava pensando que seria vantajoso ter um usuário com permissões superiores ao usuário raiz.
Veja, eu gostaria de manter todas as atividades e quase todos os privilégios de usuário raiz existentes exatamente como estão agora.
No entanto, eu gostaria da capacidade de negar privilégios para enraizar em uma base extremamente isolada caso a caso.
Uma das vantagens disso permite-me evitar que certos arquivos indesejados sejam instalados durante as atualizações. Este é apenas um exemplo de uma possível vantagem.
Como as atualizações do apt-get são executadas por root ou com privilégios sudo, o apt-get tem a capacidade de substituir certos arquivos indesejados durante as atualizações.
Se eu pudesse negar esses privilégios a esses arquivos individuais específicos, poderia defini-los como um simlink para /dev/null ou possivelmente ter um arquivo de espaço reservado em branco que poderia ter permissões que impediriam a substituição do arquivo durante a atualização. / p>
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 raiz ", que foi uma referência a como as atualizações do sistema são realizadas com permissão de root.
Simplesmente alterar o procedimento de instalação para dizer o trabalho em torno deste problema não é absolutamente o que eu estou interessado aqui. Agora que minha mente tem um gosto pela idéia de ter o poder de negar o acesso à raiz, gostaria de descobrir uma maneira de fazer isso acontecer apenas por uma questão de fazê-lo.
Eu apenas pensei sobre isso e não gastei 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 ideia ou conceito novo.
Basicamente, parece que deve haver alguma maneira de ter um super superusuário que tenha permissão além 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. também.
Eu gostaria de criar um usuário real mais alto na árvore (eu), mas acho que vou ter que sentar um dia quando tiver tempo para descobrir isso.
Além disso, não estou tentando usar o Ubuntu aqui; Eu não usaria isso como minha distro principal se eu me sentisse negativo sobre isso.
O "usuário" que você quer é chamado de módulo de segurança LSM: Linux. Os mais conhecidos são o SELinux e o AppArmor.
Por isso, você pode impedir que determinados binários (e seus processos filhos) façam certas coisas (mesmo se o seu UID for root ). Mas você pode permitir essas operações para getty e seus processos filhos para que você possa fazer isso manualmente.
Você está entendendo mal o conceito do usuário root .
Em inglês claro, root está no "topo da árvore".
E se você decidir um dia ter um "superusuário super" e, no mês que vem, um "super superusuário" (!). Quão longe "para cima" a árvore você quer 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 é root . Fim da história.
As soluções dadas aqui - incluindo AppArmor e SELinux - realmente não mudam isso. Eles simplesmente permitem um controle mais refinado sobre as permissões e processos de root .
Parece-me que o seu processo de atualização não é adequado para o resultado desejado. Mas isso não é uma falha do usuário root . Em vez de complicar demais as coisas, pense em root como o usuário de permissão de nível mais alto e, depois, em todo o resto, você precisa trabalhar para baixo.
Eu sei que algumas pessoas vão marcar isso, mas não há um nível mais alto na hierarquia de usuários, e todas as outras soluções simplesmente dão um controle ligeiramente diferente sobre como root permissõ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 root porque root representa o nível mais alto de permissões possíveis. Usar uma frase como "mais controle do que raiz" é uma contradição - root tem controle total e todas as permissões possíveis, então não há nada que possa ser feito acima dela.
Se você quiser apenas 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 container / namespace para impedir o acesso root, mas isso parece um exagero para o que você precisa.
Em vez de ter um superusuário, você pode limitar o root. Vejo Quais são os diferentes maneiras de definir permissões de arquivos, 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 completos. Você pode configurá-lo para que um usuário possa executar somente comandos pré-acordados, com argumentos pré-acordados.
Você também pode usar a virtualização para restringir a raiz:
Veja também etckeeper : esta revisão de ferramenta controla o diretório /etc e sincroniza com o apt. Por padrão, não é seguro, uma instalação mal-intencionada pode sabotá-lo, mas também é possível obtê-lo para enviar alterações para um repositório de backup com firewall.
Uso do controle de revisão em geral, com um repositório de backup com firewall. Isso ajuda na 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 de máquina virtual).
Para softwares como o APT , que na operação normal requerem acesso a quase todo o sistema, a restrição é problemática. Mesmo se você impedir que ele acesse certas partes do sistema, é mais provável que existam possibilidades suficientes para o distribuidor mal-intencionado trabalhar. Por exemplo, substituindo uma biblioteca ou apenas um binário ou adicionando uma alteração de configuração maliciosa, que a raiz irrestrita irá usar eventualmente.
Dependendo de quanto você colocaria restrições, alguns scripts de instalação podem ser interrompidos.
Para formas de restringir aplicativos e usuários, você pode escrever uma política do AppArmor ou do SELinux. Tal política seria mais suportada depende da sua distribuição: Baseada no Debian tem melhor suporte para o AppArmor enquanto distribuições baseadas no Fedora / RHEL habilitam o SELinux por padrão.
Tanto o AppArmor quanto o SELinux funcionam em políticas lista branca , que contêm regras para permitir (ou negar) ações específicas. As políticas são aplicadas a um processo em exec , da mesma forma, os usuários podem ser restringidos quando uma política é aplicada a seus processos no log-in. Uma política bem pensada não pode ser contornada (se os bugs do kernel não forem considerados). O processo confinado em execução como raiz (uid 0) é restrito pela política configurada e não pode ser alterado, a menos que explicitamente permitido na política.
A linguagem de política do AppArmor define uma regra de negação , que pode ser usada para construir uma política de lista negra . Um bom lugar para começar com o AppArmor é o AppArmor man pages , wiki e procurando a configuração existente em sua distribuição em /etc/apparmor.d/ .
O material de administração e desenvolvimento do SELinux é fornecido em wiki do SELinux . A política de referência do SELinux está hospedada no github.
Eu não acredito que ninguém tenha mencionado apt pinning ...
Há alguns anos, a Microsoft lançou um patch que quebrava as máquinas do Windows 10 de conversarem 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 apt ainda funcionava corretamente.
Um completo Passo a passo Debian explica bem o processo:
Em /etc/apt/preferences (ou um novo arquivo em /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 que fixamos em uma versão do pacote. A raiz poderia contorná-la, como o root sempre pode fazer, mas isso resolve o problema dos gerenciadores de pacotes que tentam atualizar pacotes automaticamente em você.
OBSERVAÇÃO: esta resposta supõe que você tenha um problema XY
Na verdade, é bem simples.
Root é seu "super super usuário"
Crie uma conta chamada "admin" e dê a ele todas as permissões do root, exceto a que você não deseja.
Em seguida, crie um usuário chamado bob e deixe-o "tornar-se administrador". Usando su ou até mesmo sudo.
Agora você tem um usuário normal (bob), um superusuário que pode fazer material administrativo (admin) e um superusuário (root).
Se você quiser mudar o nome "root" para outra coisa, você pode até fazer isso. Tecnicamente, apenas o ID do usuário (0) é importante.
Se o que você deseja é simplesmente impedir que arquivos específicos sejam instalados, restringir as permissões de root não é o caminho a ser feito. Vale a pena notar também que as respostas convencionais (arquivos imutáveis ou LSM's) não funcionarão para o seu caso de uso particular, já que o APT (e a maioria dos outros gerenciadores de pacotes), salvará se não puder instalar arquivos.
A verdadeira questão que você quer perguntar é:
Existe uma maneira de impedir que o APT instale arquivos específicos?
Isso é algo completamente diferente do que você está fazendo em vários níveis.
Agora, quanto a essa pergunta, não tenho 100% de certeza, mas sei que vários outros gerenciadores de pacotes têm opções para impedir que arquivos específicos sejam instalados (por exemplo, o sistema Portage do Gentoo tem a opção INSTALL_MASK= , que na verdade aceita padrões de correspondência de estilo de shell para não instalar). Eu estaria mais do que disposto a apostar que tal opção existe para o APT (ou possivelmente o próprio dpkg).
Coloque uma cópia de backup em um lugar seguro. Após qualquer instalação / atualização, substitua imediatamente os arquivos específicos desse backup. Assim, não há erros para estragar a instalação, mas você ainda recebe de volta o (s) arquivo (s) que deseja manter.
Note que isso é principalmente uma resposta conceitual, mas acho que deve funcionar e estar em espírito com o que você quer alcançar.
Deixe o sistema X ser o seu sistema de trabalho, e o sistema Y outro sistema que você controla
Agora você tem sua 'raiz de trabalho' que pode fazer quase tudo, e você tem sua 'super raiz', a conta raiz real do sistema Y, que pode realmente fazer tudo.
Você pode executar um hipervisor de tipo 1, como hipervisor Xen & ter que hospedar seu sistema operacional regular como um convidado virtualizado. O hipervisor controla o sistema operacional convidado virtual em um nível "mais profundo" do que o de raiz porque ele tem controle sobre o hardware (virtual) no qual o sistema operacional guest é executado.
Você pode programar o hipervisor para manipular o sistema operacional convidado de várias maneiras, incluindo a alteração de permissões, criando & aplicar backups, ligar certas alterações ou instruções no sistema operacional convidado para injetar funcionalidade adicional, validação, etc. Essa seria uma maneira válida e potencialmente útil de implementar um sistema de tipo unix com um "usuário" (na verdade, uma função do hipervisor) para "fazer coisas que o root não pode fazer"
Minha sensação de que essa abordagem é provavelmente excessiva
Dê uma olhada nos cgroups e Espaços para nome do Linux como um método alternativo para atingir esse tipo de meta, bem como ferramentas baseadas neles, como o Docker e lxd .
Essas ferramentas permitem, entre outras coisas, limitar quais partes do sistema de arquivos um processo executado como "root" pode ver, limitar quais processos são visíveis a ele e fornecer apenas alguns capabilities para o usuário "root".
sudo
Que tal desinstalar sudo e symlink /bin/su para /bin/false ? Junte isso certificando-se de que root não pode fazer login via ssh e você bloqueou o sistema.
Isso torna root o Super * Super User e todo mundo está subordinado a isso.
Para arquivos substituídos durante as atualizações, simplesmente não faça atualizações. Mais realisticamente, altere as permissões dos arquivos para 440 ou 444 para que não possam ser gravados. Ou coloque-os em um repositório git, para que, se forem sobrescritos, possam ser revertidos.
Tags sudo permissions root users