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

Question

Depois de ler algumas respostas bem legais da esta pergunta , ainda estou confuso sobre por que você iria querer fingir que você é raiz sem obter nenhum dos benefícios de realmente ser root.

Até agora, o que eu posso descobrir é que o fakeroot é usado para dar posse a um arquivo que precisa ser root quando é descompactado / tarado. Minha pergunta é por que você não pode fazer isso com chown?

Um debate dos Grupos do Google aqui indica que você precisa do fakeroot para compilar um kernel do Debian (se você quiser fazer isso de 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 permita a compilação (o que significa que o gcc agora pode ler um arquivo que era para root)?

Esta resposta aqui descreve que as chamadas reais do sistema são feitas com uid / gid real do user , então novamente onde o fakeroot ajuda?

Como o fakeroot impede escalações de privilégios indesejados no Linux? Se o fakeroot pode enganar o tar ao criar um arquivo que pertence ao root, por que não fazer algo semelhante com o SUID?

Pelo que eu aprendi, o fakeroot é útil apenas quando você quer mudar o dono de qualquer arquivo de pacote que você construiu para o root. Mas você pode fazer isso com chown, então, onde eu não entendo como esse componente deve ser usado?

    

Answer 1

So far, what I can gather is that fakeroot is used to give ownership to a file that needs to be root when it is unzip/tar'ed. My question, is why can't you just do that with chown?

Porque você não pode fazer isso com chown , pelo menos não como usuário não raiz. (E se você está rodando como root, você não precisa de fakeroot .) Esse é o objetivo de fakeroot : permitir que programas que esperam ser executados como root sejam executados como um usuário normal, enquanto fingem que o operações que exigem raiz têm sucesso.

Isso é usado normalmente ao criar um pacote, para que o processo de instalação do pacote sendo instalado possa continuar sem erros (mesmo se for executado chown root:root ou install -o root , etc.). fakeroot lembra-se da propriedade falsa que pretendia dar aos arquivos, de modo que as operações subsequentes que analisam a propriedade veem isso em vez do real; isso permite que as correções tar subseqüentes, por exemplo, armazenem arquivos de propriedade de root.

How does fakeroot stop unwanted privilege escalations on Linux? If fakeroot can trick tar into making a file that was owned by root, why not do something similar with SUID?

fakeroot não engana tar ao fazer nada, preserva as alterações que a compilação deseja realizar sem permitir que essas alterações entrem em vigor no sistema que hospeda a compilação. Você não precisa de fakeroot para produzir um tarball contendo um arquivo de propriedade de root e suid; se você tiver um binário evilbinary , executando tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary , como um usuário comum, criará um tarball contendo evilbinary , de propriedade root e suid. No entanto, você não poderá extrair esse tarball e preservar essas permissões, a menos que você faça isso como root: não há escalonamento de privilégios aqui. fakeroot é uma ferramenta de privilégio de -escala: permite executar uma compilação como um usuário comum, preservando os efeitos que a compilação teria se fosse executada como raiz, permitindo esses efeitos para ser repetido mais tarde. Aplicar os efeitos “de verdade” sempre requer privilégios de root; fakeroot não fornece nenhum método para adquiri-los.

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

• instalar arquivos, de propriedade do root
• ...
• arquiva esses arquivos, que ainda são de propriedade do root, para que, quando forem extraídos, eles sejam de propriedade do root

A primeira parte obviamente falha se você não for root. No entanto, quando executado sob fakeroot , como usuário normal, o processo se torna

• instalar arquivos de propriedade do root - isso falha, mas fakeroot finge que é bem-sucedido, e lembra a propriedade alterada
• ...
• arquiva esses arquivos, que ainda são de propriedade do root - quando tar (ou qualquer arquivador está sendo usado) pergunta ao sistema qual é a propriedade do arquivo, fakeroot altera a resposta para corresponder à propriedade registrada anteriormente

Assim, você pode executar uma compilação de pacote sem ser root e obter os mesmos resultados obtidos 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, por isso, um processo de instalação desonesto não pode danificar seu sistema (além de tocar em seus arquivos).

No Debian, as ferramentas de compilação foram melhoradas para não exigir mais isso, e você pode compila pacotes sem fakeroot . Isso é suportado por dpkg diretamente com a diretiva Rules-Requires-Root (consulte rootless-builds.txt ).

Para entender o objetivo de fakeroot e os aspectos de segurança da execução como raiz ou não, isso pode ajudar a considerar o propósito do empacotamento. Quando você instala um software a partir do código-fonte, para uso em todo o sistema, você procede da seguinte forma:

1. construa o software (o que pode ser feito sem privilégios)
2. instala o software (que precisa ser feito como raiz ou, pelo menos, como um usuário pode gravar nos locais apropriados do sistema)

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

1. construa o software (sem privilégios especiais)
2. pretende instalar o software (novamente sem privilégios especiais)
3. capture a instalação do software como um pacote (idem)
4. disponibiliza o pacote (idem)

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

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

    

Answer 2

NÃO. Raiz falsa permite que você execute a manipulação de permissões e ferramentas de relatório, ele irá reportar de forma consistente. No entanto, ele não concederá essas permissões. Vai parecer que você os tem (falso). Não vai mudar nada fora do ambiente.

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

não realmente eleva as permissões, é falso. Ele não permite fazer nada (excluir, escrever, 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 acesso ou qualquer coisa que você não possa fazer sem ela. Ele é executado sem privilégios. Tudo o que é dose é interceptar chamadas para chown , chmod , etc. Isso faz com que elas não funcionem, exceto que registra o que teria acontecido. Ele também intercepta as chamadas para stat etc., de modo que ele relate permissões e propriedade, a partir de seu próprio banco de dados interno, como se os outros comandos tivessem sido executados. Isso é útil, porque se você zipar o diretório, ele terá as permissões falsas. Se você descompactar, como root, as permissões se tornarão reais.

Qualquer arquivo que não seja legível / gravável antes, permanecerá legível / gravável. Quaisquer arquivos especiais (por exemplo, dispositivos) criados não terão poderes especiais. Qualquer arquivo set-uid (para outro usuário), os arquivos não serão set-uid. Qualquer outro escalonamento de privilégios não funcionará.

É um tipo de máquina virtual: uma máquina virtual, em geral, pode simular qualquer ambiente / SO, mas não pode fazer nada ao 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 isso tudo irá existir no host, como recursos pertencentes ao usuário / grupo do processo executando o ambiente virtual.

    

Answer 3

Já existem duas respostas boas e muito detalhadas aqui, mas vou apenas salientar que o parágrafo introdutório das manpages original fakeroot página do manual ¹ explica de forma clara e concisa:

fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership. Without fakeroot one would need to have root privileges to create the constituent files of the archives with the correct permissions and ownership, and then pack them up, or one would have to construct the archives directly, without using the archiver.

O Fakeroot permite que um usuário não-root crie arquivos contendo arquivos de propriedade da raiz, o que é uma parte crítica da geração e distribuição de pacotes de software binários no Linux. Sem fakeroot , os arquivos de pacotes teriam que ser gerados durante a execução como raiz real, para que eles contivessem a propriedade e permissões de arquivo corretas. Esse seria um risco de segurança. Construir e empacotar software potencialmente não confiável é uma grande exposição se feito com privilégios de root. Graças a fakeroot , um usuário não privilegiado com arquivos não privilegiados ainda pode gerar arquivos contendo arquivos com propriedade de raiz. ²

Mas não é um risco de segurança, porque nada no arquivo é de fato de propriedade da raiz até que os arquivos estejam EXTRACTED . E, mesmo assim, os arquivos só serão extraídos com suas permissões de raiz intactas se forem feitos por um usuário privilegiado. Essa etapa - em que um arquivo fakeroot -assisted contendo arquivos "raiz" é extraído por um usuário privilegiado - é onde a raiz "falsa" finalmente se torna real. Até esse ponto, nenhum privilégio real do root é obtido ou ignorado.

Notas

1. O Fakeroot gerou alguns concorrentes / imitadores que se mascararão como fakeroot se instalados, incluindo fakeroot-ng e pseudo . Mas IMHO nem a página de manual do "imitador" é quase tão clara quanto a ir direto ao ponto nesta questão. Fique com o original, um e apenas fakeroot O.G.

2. Outras distribuições / sistemas de empacotamento superam isso simplesmente não usando a propriedade raiz 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 a necessidade de fakeroot . Tudo é feito dentro do $HOME/rpmbuild/ space do usuário, e etapas normalmente privilegiadas como make install são redirecionadas (por meio de mecanismos como --prefix e DESTDIR ) para uma $HOME/rpmbuild/BUILDROOT/ hierarchy que pode ser considerada uma espécie de "fakechroot" espaço (sem realmente usar fakechroot ).

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