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.

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.

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.

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.

• 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).

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.

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

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.

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).

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.

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.

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

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".

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.