Como o fakeroot não é uma violação de segurança no Linux?


18

Depois de ler algumas respostas bastante legais dessa pergunta , ainda estou confuso sobre o motivo pelo qual você deseja fingir que é root sem obter nenhum dos benefícios de realmente ser root.

Até agora, o que posso concluir é que o fakeroot é usado para dar propriedade a um arquivo que precisa ser root quando é descompactado / tar'ed. Minha pergunta é: por que você não pode simplesmente fazer isso com o chown?

Uma discussão nos Grupos do Google aqui indica que você precisa do fakeroot para compilar um kernel do Debian (se você quiser fazê-lo por um usuário sem privilégios). Meu comentário é que, o motivo pelo qual você precisa ser root para compilar é provavelmente porque as permissões de leitura não foram definidas para outros usuários. Em caso afirmativo, não é uma violação de segurança que o fakeroot permite a compilação (o que significa que o gcc agora pode ler um arquivo que era raiz)?

Esta resposta aqui descreve que as chamadas reais do sistema são feitas com o uid / gid real do usuário . Então, novamente, onde o fakeroot ajuda?

Como o fakeroot interrompe escalações indesejadas de privilégios no Linux? Se o fakeroot pode induzir o tar a criar um arquivo que pertence à raiz, por que não fazer algo semelhante ao SUID?

Pelo que eu coletei, o fakeroot é útil apenas quando você deseja alterar o proprietário de qualquer arquivo de pacote criado para raiz. Mas você pode fazer isso com o chown, então , onde me falta a compreensão de como esse componente deve ser usado?


11
Você não precisa do fakeroot para compilar um kernel. O sistema de compilação do kernel não é tão louco. A discussão vinculada é sobre como criar um pacote de kernel Debian , no qual a compilação real do kernel é apenas um passo.

@ WumpusQ.Wumbley vou corrigir isso, e você poderia me dizer por que esse é o caso?
ng.newbie

Porque o fakeroot é uma coisa do Debian e o Linux é mais do que o Debian?

@ WumpusQ.Wumbley deve ser executado em qualquer distribuição.
user253751

Respostas:


33

Até agora, o que posso concluir é que o fakeroot é usado para dar propriedade a um arquivo que precisa ser root quando é descompactado / tar'ed. Minha pergunta é: por que você não pode simplesmente fazer isso com o chown?

Porque você não pode simplesmente fazer isso com chown, pelo menos não como um usuário não root. (E se você estiver executando como root, não precisará fakeroot.) Esse é o objetivo fakeroot: permitir que os programas que esperam ser executados como root sejam executados como um usuário normal, enquanto fingem que as operações que exigem root são bem-sucedidas.

Isso é usado normalmente ao criar um pacote, para que o processo de instalação do pacote que está sendo instalado possa continuar sem erros (mesmo que seja executado chown root:root, ou install -o rootetc.). fakerootlembra-se da propriedade falsa que pretendia fornecer arquivos; portanto, as operações subsequentes que examinam a propriedade veem isso em vez do real; isso permite tarexecuções subsequentes, por exemplo, para armazenar arquivos pertencentes à raiz.

Como o fakeroot interrompe escalações indesejadas de privilégios no Linux? Se o fakeroot pode induzir o tar a criar um arquivo que pertence à raiz, por que não fazer algo semelhante ao SUID?

fakerootnão se engana tarao fazer nada, preserva as alterações que a compilação deseja fazer sem permitir que essas alterações tenham efeito no sistema que hospeda a compilação. Você não precisa fakerootproduzir um tarball contendo um arquivo pertencente a root e suid; se você possui um binário evilbinary, executando tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary, como usuário comum, criará um tarball contendo evilbinary, de propriedade de root e suid. No entanto, você não poderá extrair esse tarball e preservar essas permissões, a menos que faça isso como root: não há escalação de privilégios aqui. fakerooté um privilégio de-escalation tool: permite executar uma compilação como um usuário comum, preservando os efeitos que a compilação teria se tivesse sido executada como raiz, permitindo que esses efeitos fossem reproduzidos posteriormente. Aplicar os efeitos "de verdade" sempre requer privilégios de root; fakerootnão fornece nenhum método para adquiri-los.

Para entender o uso de fakerootmais detalhes, considere que uma construção de distribuição típica envolve as seguintes operações (entre muitas outras):

  • instalar arquivos pertencentes à raiz
  • ...
  • arquive esses arquivos, ainda de propriedade de raiz, para que, quando extraídos, sejam de propriedade de raiz

A primeira parte obviamente falha se você não é root. No entanto, quando executado fakerootcomo um usuário normal, o processo se torna

  • instalar arquivos pertencentes ao root - isso falha, mas fakerootfinge que é bem-sucedido e lembra a propriedade alterada
  • ...
  • arquivar esses arquivos, ainda de propriedade do root - quando tar(ou qualquer outro arquivador que estiver sendo usado) perguntar ao sistema qual é a propriedade do arquivo, fakerootaltera a resposta para corresponder à propriedade registrada anteriormente

Assim, você pode executar uma compilação de pacotes sem ser root, enquanto obtém os mesmos resultados que obteria se estivesse realmente executando como root. Usar fakerooté mais seguro: o sistema ainda não pode fazer nada que seu usuário não possa fazer, portanto, um processo de instalação não autorizado não pode danificar seu sistema (além de tocar em seus arquivos).

No Debian, as ferramentas de construção foram aprimoradas para não exigir mais isso, e você pode construir pacotes semfakeroot . Isso é suportado dpkgdiretamente pela Rules-Requires-Rootdiretiva (consulte rootless-builds.txt).

Para entender a finalidade fakeroote os aspectos de segurança da execução como raiz ou não, pode ajudar a considerar a finalidade do empacotamento. Ao instalar um software da fonte, para uso em todo o sistema, proceda da seguinte maneira:

  1. construir o software (que pode ser feito sem privilégios)
  2. instale o software (que precisa ser feito como root ou, pelo menos, como um usuário autorizado a gravar nos locais apropriados do sistema)

Quando você empacota um software, está atrasando a segunda parte; mas para fazer isso com sucesso, você ainda precisa “instalar” o software no pacote e não no sistema. Portanto, quando você empacota o software, o processo se torna:

  1. construir o software (sem privilégios especiais)
  2. fingir instalar o software (novamente sem privilégios especiais)
  3. capturar a instalação do software como um pacote (idem)
  4. disponibilizar o pacote (idem)

Agora, um usuário conclui o processo instalando o pacote, que precisa ser feito como root (ou novamente, um usuário com os privilégios apropriados para gravar nos locais apropriados). É aqui que o processo privilegiado atrasado é realizado e é a única parte do processo que precisa de privilégios especiais.

fakeroot ajuda nas etapas 2 e 3 acima, permitindo executar processos de instalação de software e capturar seu comportamento, sem executar como root.


11
@ ng.newbie Se você quiser uma explicação alternativa: é totalmente possível para mim usar um editor hexadecimal para construir manualmente um arquivo tar contendo arquivos pertencentes à raiz ou com outras permissões possíveis. Afinal, são apenas algumas informações agrupadas, não tem poder até que o arquivo realmente exista no sistema.
mbrig

@ ng.newbie Você desenrola com fakeroot ou sem fakeroot?
user253751

2
@ ng.newbie, além disso, se você quiser criar um tarball com um binário suid-root para fins maliciosos, poderá fazer isso em outra máquina como raiz real e copiá-lo para o destino. Não há necessidade de fakeroot lá. O fakeroot é apenas uma ferramenta para ajudar na criação do arquivo tar, elimina a necessidade de uso tar --mode --ownerpara cada arquivo adicionado ao arquivo (e também funciona com outros programas). Os problemas em potencial surgem se / quando você descompacta um arquivo tar ou arquivo morto não confiável como raiz, e não quando o cria.
22918 ilkkachu

7

NÃO. A raiz falsa permite que você execute ferramentas de manipulação de permissões e relatórios, que serão relatadas de forma consistente. No entanto, ele realmente não concederá essas permissões. Apenas parecerá que você os possui (falso). Não mudará nada fora do ambiente.

É útil, se você deseja criar uma estrutura de diretórios que contenha propriedade e permissões, que não podem ser definidas pelo usuário, que você irá tar, zip ou outro pacote.

Ele não realmente elevar as permissões, é falso. Não permite que você faça nada (excluir, gravar, ler) que você não poderia fazer de outra forma. Você poderia produzir o pacote (em teoria) sem ele. Você pode obter um relatório falso ( ls) sem ele.

Não é uma falha de segurança, porque não permite o acesso ou qualquer coisa que você não possa fazer sem ele. É executado sem privilégios. Tudo o que é dose é interceptar as chamadas para chown, chmodetc. Isso as torna inoperantes, exceto que registra o que teria acontecido. Ele também intercepta chamadas para statetc. para relatar permissões e propriedade, de seu próprio banco de dados interno, como se os outros comandos tivessem sido executados. Isso é útil porque, se você compactar o diretório, ele terá permissões falsas. Se você descompactar, como root, as permissões se tornarão reais.

Quaisquer arquivos que não sejam legíveis / graváveis ​​antes, permanecerão não legíveis / graváveis. Quaisquer arquivos especiais (por exemplo, dispositivos) criados, não terão poderes especiais. Qualquer arquivo set-uid (para outro usuário) não será configurado. Qualquer outra escalação de privilégios não funcionará.

É um tipo de máquina virtual: uma máquina virtual, em geral, pode simular qualquer ambiente / sistema operacional, mas não pode fazer nada para o host, o que qualquer outro aplicativo não poderia fazer. Dentro da máquina virtual, você pode parecer fazer qualquer coisa. Você pode reinventar o sistema de segurança para ser o mesmo ou diferente. No entanto, tudo isso existirá no host, como recursos pertencentes ao usuário / grupo do processo que está executando o ambiente virtual.


@ ctrl-alt-decor Como pedi no comentário acima, no * nix não é possível configurar o proprietário para fazer root em outro usuário não privilegiado, correto? Portanto, deve haver uma boa razão para isso, se um programa permitir, como isso não é uma falha de segurança?
ng.newbie

@ ctrl-alt-decor O fakeroot não me permite ler / gravar / excluir, mas se eu escrevi um wrapper para os syscalls, é lógico que eu também possa fazer essas operações.
ng.newbie

@ ctrl-alt-decor Portanto, a única razão para o fakeroot existir é definir permissões para um arquivo como root sem ser root. Se isso não é uma falha de segurança, por que o Linux não permitiria isso em primeiro lugar?
ng.newbie

11
Não, permite falsificar a configuração de usuário para qualquer usuário e falsificar algumas outras coisas. Experimente: execute o fakeroot e veja os arquivos de fora, tente acessar os arquivos que você não deveria.
CTRL-ALT-DELOR 11/07/19

4

Já existem duas respostas boas e muito detalhadas aqui, mas vou apenas salientar que o parágrafo introdutório da página de manual original 1 na verdade explica de maneira bem clara e concisa:fakeroot

O fakeroot executa um comando em um ambiente em que parece ter privilégios de root para manipulação de arquivos. Isso é útil para permitir que os usuários criem arquivos (tar, ar, .deb etc.) com arquivos neles com permissões / propriedade raiz. Sem o fakeroot, seria necessário ter privilégios de root para criar os arquivos constituintes dos arquivos com as permissões e a propriedade corretas e depois empacotá-los, ou seria necessário construir os arquivos diretamente, sem usar o arquivador.

O Fakeroot permite que um usuário não root crie arquivos que contenham arquivos de propriedade raiz, o que é uma parte crítica da geração e distribuição de pacotes de software binários no Linux. Sem isso fakeroot, os arquivos do pacote precisariam ser gerados durante a execução como raiz real, para que eles contenham a propriedade e as permissões corretas. Isso seria um risco de segurança. Construir e empacotar software potencialmente não confiável é uma enorme exposição se feito com privs raiz. Graças a fakeroot, um usuário sem privilégios com arquivos sem privilégios ainda pode gerar arquivos contendo arquivos com propriedade de root. 2

Mas não é um risco de segurança, porque nada no arquivo é realmente de propriedade da raiz até que os arquivos são EXTRAÍDO . E mesmo assim, os arquivos serão extraídos apenas com suas permissões de root intactas se forem feitos por um usuário privilegiado. Essa etapa - onde um fakerootarquivo assistido que contém arquivos "raiz" é extraído por um usuário privilegiado - é onde a raiz "falsa" finalmente se torna real. Até esse ponto, nenhum privilégio root real é obtido ou ignorado.

Notas

  1. O Fakeroot gerou alguns concorrentes / imitadores que se disfarçam como fakerootse instalados, incluindo fakeroot-nge pseudo. Mas a IMHO, nem a página de manual do "imitador" é tão clara quanto a ir direto ao ponto nesta questão. Fique com o original, o único fakerootOG
  2. Outras distribuições / sistemas de empacotamento superam isso simplesmente não usando a propriedade de root em seus arquivos de pacotes. No Fedora, por exemplo, o software pode ser compilado, instalado e empacotado por um usuário sem privilégios, sem necessidade fakeroot. Tudo é feito no $HOME/rpmbuild/espaço do usuário e etapas normalmente privilegiadas, como make installredirecionadas (por meio de mecanismos como --prefixe DESTDIR), para uma $HOME/rpmbuild/BUILDROOT/hierarquia que pode ser considerada uma espécie de espaço "fakechroot" (sem realmente usar fakechroot).

    Mas, mesmo durante make install, tudo é executado como pertencente ao usuário sem privilégios. A propriedade e as permissões do arquivo extraído serão definidas como root,roote 0644(ou 0755para executáveis) por padrão, a menos que sejam substituídas no .specarquivo de definição de pacote ( ), caso em que são armazenadas como metadados no pacote final. Como nenhuma permissão ou propriedade é realmente aplicada até o processo de instalação (privilegiado) do pacote rpm, nem o root nem o fakerootnecessário durante o empacotamento. Mas fakerooté realmente apenas um caminho diferente para o mesmo resultado.


11
Com relação à sua primeira nota, fakeroot-ng afirma- se substituir fakeroot, mas na prática ela não a substituiu, e o AFAIK fakerootainda é a ferramenta usada no Debian por padrão (quando necessário).
Stephen Kitt

@StephenKitt Aha! Obrigado. Eu estava me perguntando sobre isso. Inicialmente, fiquei confuso porque procurei a página de fakerootmanual, e o Google me largou na casa fakeroot-ngde (disfarçado de fakeroot(1)), e acho que fiquei com excesso de presunção. Mas agora vejo que o fakeroot-ng não é atualizado desde 2014 , enquanto o fakeroot ainda está ativo . Aparentemente, também há pseudo que fez isso há alguns anos, mas agora parou. Vou ajustar minha resposta de acordo.
FeRD

11
Sim, eu também fiquei confuso no começo, já que a página de fakerootmanual no site do Debian leva à fakeroot-ngversão do padrão por padrão. Confira o último parágrafo do fakeroot-ngpara uma torção divertida ;-).
Stephen Kitt
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.