Toolbox: Ambientes de desenvolvimento isolados para se proteger contra bugs e malware no código em desenvolvimento

Você quer um contêiner de usuário persistente sem seu / home? Só estou tentando entender melhor o requerimento / caso de uso. - Por exemplo, comparado a apenas executar um contêiner Fedora descartável padrão?

Considere uma conta Unix que é usada tanto para casa quanto para o trabalho. Para um contêiner de trabalho, posso preferir montar apenas meu diretório de trabalho no contêiner.

Considere um aplicativo GUI não confiável. Ele pode precisar apenas de acesso a uma pasta específica para carregar / salvar arquivos. Ele não precisa de acesso à minha pasta .ssh e outros arquivos não relacionados.

Para melhorar a segurança, o Chrome OS não compartilha pastas com contêineres por padrão do host. Lá, se você deseja fornecer dados aos contêineres de seu diretório inicial ou de uma unidade USB, você os compartilha explicitamente.

A conteinerização como recurso de segurança perde um valor significativo se você fornecer ao contêiner não confiável todos os seus dados por padrão!

@juhp Vejo que você trabalha muito com pacotes Haskell. Presuma que um dos pacotes Haskell que você está instalando remotamente foi comprometido. Os pacotes Haskell precisam acessar sua pasta .ssh ou sua carteira Bitcoin? Por que compartilhar tudo em seu ambiente de desenvolvimento Haskell por padrão?

Recentemente, houve um módulo NPM que ainda poderia Bitcoin local se estivesse instalado:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

O módulo era popular e, de fato, minha equipe o instalou em nossa árvore. Não atendemos aos outros critérios para desencadear um roubo de bitcoin, mas esse risco teria sido completamente mitigado se nosso ambiente de desenvolvimento não tivesse acesso completo aos nossos diretórios pessoais por padrão. Nenhum funcionário teria optado por compartilhar sua carteira Bitcoin neste ambiente de desenvolvimento.

Isso é totalmente válido, mas vai ser difícil.

Na prática, acho que o melhor caminho é facilitar a execução de caixas de ferramentas como usuários separados (criar temporariamente novos uids, cada um com seu próprio /home ) - requer um serviço de sistema privilegiado para fazer isso.

Agora, se você quiser compartilhar alguns arquivos, por exemplo, somente leitura - ficará mais confuso.

É possível excluir arquivos / dirs de uma montagem de ligação de diretório?

Para ter certeza de que entendi o desafio, vejo que a montagem do diretório inicial acontece em uma linha de código

    --volume "$HOME":"$HOME":rslave

Mas o desafio aqui ainda é fazer os aplicativos GUI e alguns outros recursos funcionarem, porque esses recursos esperam que o usuário dentro e fora do contêiner seja o mesmo?

Este é realmente um recurso bastante importante. Acho que não há problema em montar home por padrão, mas deve ser possível usar um contêiner de maneira não confiável. A montagem inicial em um contêiner pressupõe que você confie no contêiner, o que em um contêiner descartável geralmente não é o caso. Mesmo em casos simples, como testar algum módulo do NPM, gostaria de ter a tranquilidade de saber que isso não vai destruir minha pasta de início.

@markstos talvez você possa testar o que pode fazer sem o home mount ou apenas montando um diretório específico (cwd)?

@juhp Na verdade, isso foi um obstáculo para mim - parei de avaliar o Silverblue assim que encontrei esse recurso que faltava. Se isso for endereçado, posso dar uma segunda olhada em Silverblue. Também fiquei desapontado ao descobrir que não foi fácil descobrir como executar um contêiner do Ubuntu, que é o sistema operacional que usei antes.

Se o Fedora deseja dar as boas-vindas aos usuários vindos de outras distros Linux, facilitar a execução de sua distro antiga em um contêiner seria um bom lugar para começar.

@markstos obrigado - sou apenas mais um usuário do Toolbox. :-)
Concordo plenamente que estender o Toolbox para oferecer suporte a mais sistemas operacionais seria muito útil.
Observe que o Toolbox também funciona sem o Silverblue (ou seja, em outras edições do Fedora).

@juhp Na verdade, isso foi um obstáculo para mim - parei de avaliar o Silverblue assim que encontrei esse recurso que faltava

o que você fez antes? Existe alguma outra ferramenta / abordagem que você estava usando que não funcionou no Silverblue?

Nada o impede de, por exemplo, usar uma VM descartável (como QubesOS), ou ter um script personalizado que implementa algumas das sugestões deste tópico. Indiscutivelmente, devemos ser mais opinativos e incorporar uma funcionalidade semelhante ao QubesOS no Silverblue.

Mas, de qualquer maneira, a tecnologia existente de VM e contêiner está lá. Na verdade, toolbox hoje é realmente um monte de scripts que fazem podman borrar intencionalmente com o host. Se você não quiser a integração, pode começar com podman run ... já que esse é o padrão.

@cgwalters Comecei a usar o Chrome OS em meu laptop pessoal e Crostini . Eu gosto que ele suporta aplicativos GUI, bem como aplicativos de linha de comando. Também gosto que os contêineres sejam privados por padrão. Tenho que compartilhar explicitamente pastas de dados ou drives USB com eles. Por outro lado, o suporte de som e wayland é configurado automaticamente nesses contêineres.
url
Estive avaliando soluções semelhantes para usar em meu laptop de trabalho. Uma opção seria o Cloudready da Neverware - um Chrome OS de código aberto para hardware de PC. Às vezes, há portas em que o Crostini trava, os dados são perdidos e é necessário reiniciar. Por esse motivo, eu hesito em dobrar o ChromeOS / Crostini agora.

O Silverblue também parecia atraente até que eu descobri que ele não parecia suportar os contêineres do Ubuntu fora da caixa e compartilhava demais dos meus dados pessoais com contêineres nos quais não pretendo confiar. Eu também olhei para Clear Linux. Ele tem o mesmo conceito de executar quase tudo em contêineres. Não estou entusiasmado com os laços estreitos com a Intel e o x86. Também não é basicamente um sistema operacional de desktop. Uma opção final (padrão?) Seria manter o Ubuntu como desktop e mover mais meu trabalho de desenvolvimento para contêineres LXD, que o Crostini do Chrome está usando. Devo ser capaz de copiar contêineres LXD entre meu trabalho e laptops pessoais, embora o sistema operacional host seja diferente. Usando modelos LXD, devo ser capaz de configurar um modelo compartilhando montagens suficientes nos contêineres para suporte ao Wayland.

Nota lateral: Obrigado por todos os anos mantendo o Rhythmbox!

Talvez eu não tenha entendido bem a missão de toolbox . Do README:

.. A intenção desses sistemas é desencorajar a instalação de software no host

Porque? Com o padrão é compartilhar todos os seus dados pessoais no contêiner por padrão, não acho que uma segurança melhorada pode ser reivindicada.

O benefício potencial restante seria o isolamento, para que você pudesse instalar versões conflitantes de software lado a lado.

Se o comportamento de sempre compartilhar permanecer, pode ser útil atualizar os documentos para esclarecer que toolbox compartilha todo o seu diretório inicial nos contêineres, que o comportamento não pode ser desativado e não deve ser usado com não confiáveis containers.

Eu entendo que posso usar o podman diretamente, mas estava interessado em uma solução de contêiner com integração de GUI. Ao pesquisar como fazer isso com podman , usar toolbox é a abordagem recomendada:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos Se você estiver interessado, criei o PR # 298 que constrói uma imagem do Ubuntu 19.04.

Acho que há alguma confusão aqui.

Nosso README.md cresceu e se transformou um pouco ao longo dos meses e provavelmente é um pouco mais difícil de entender. Anteriormente, dizia simplesmente Hacking on OSTree-based Fedoras .

Se você instalar o Silverblue (ou qualquer outro sistema operacional baseado em OSTree), a dificuldade de depurar o sistema operacional ou configurar um ambiente de desenvolvimento torna-se imediatamente óbvia. A caixa de ferramentas existe para resolver esse problema.

.. A intenção desses sistemas é desencorajar a instalação de software no host

Porque? Com o padrão é compartilhar todos os seus dados pessoais no contêiner por padrão, eu
não pense que uma segurança melhorada pode ser reivindicada.

Segurança é uma palavra sobrecarregada. A Toolbox não faz nenhuma reclamação sobre isso.

Por muitas décadas, qualquer processo executado como seu UID poderia olhar para suas chaves criptográficas privadas, documentos, fotos, etc. e até mesmo transmiti-los através do planeta sem você nunca saber. Este é o status quo dos sistemas operacionais clientes de software livre.

Flatpak muda isso separando cada aplicativo gráfico e o sistema operacional em seus próprios domínios de segurança. O Silverblue solidifica essa separação ao dificultar a instalação de software diretamente na imagem do sistema operacional host. Portanto, para uma experiência de usuário tranquila, você realmente precisa usar os aplicativos fornecidos como Flatpaks.

No entanto, como mencionei no início, essa imagem bloqueada do sistema operacional apresenta seu próprio conjunto de problemas. A maneira como os resolvemos é uma troca entre conveniência e segurança. Quanto mais radical a solução, mais difícil será para os usuários Linux existentes adotar o Silverblue.

No momento, o Toolbox tende a adotar mais do que segurança; porque independentemente de você estar usando o Toolbox ou não, o Silverblue faz uma melhoria quântica no estado dos sistemas operacionais clientes de software livre e colocar isso nas mãos do usuário seria um passo positivo.

Além disso, não se trata apenas de segurança. É também uma questão de estabilidade.

É muito difícil testar uma distribuição Linux convencional. Pacotes e espelhos estão sempre sendo atualizados por colaboradores aleatórios em espelhos aleatórios em todo o mundo - a explosão combinatória só pode ser gerenciada por um elaborado sistema de congelamentos. Quando as coisas dão errado, e acontecem, também é muito difícil para um usuário reverter uma atualização, e coisas como cortes de energia no meio de uma atualização podem interromper irremediavelmente o sistema.

Um sistema operacional baseado em OSTree muda tudo isso.

Sei que posso usar o podman diretamente, mas estou interessado em uma solução de contêiner com GUI
integração. Ao pesquisar sobre como fazer isso com o podman, usar a caixa de ferramentas é
a abordagem recomendada:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

A questão é por que você deseja usar o Podman para executar aplicativos gráficos? :)

Em geral, Podman (ou um contêiner OCI) é uma opção ruim para executar aplicativos GUI. Essa é a razão pela qual Flatpak existe e o Toolbox não compete com ele.

No entanto, há uma sobreposição, no sentido de que os contêineres do Toolbox têm alguma integração com a área de trabalho, e há alguns casos em que a capacidade de executar um aplicativo GUI não Flatpaked é imensamente útil em curto prazo imediato. Pode ser que o aplicativo que você deseja ainda não tenha sido Flatpaked ou talvez a versão Flatpaked esteja faltando alguns recursos. Pode ser que você esteja trabalhando em alguma biblioteca usada por aplicativos gráficos e queira executar rapidamente um programa de teste único para ver se sua biblioteca está funcionando conforme o esperado.

O Toolbox pode, de fato, ajudar nesses casos, mas isso é diferente de dizer que o objetivo principal do Toolbox é armazenar aplicativos gráficos em contêineres. O objetivo principal do Toolbox é permitir que você hackeie um sistema operacional baseado em OSTree.

Agora, se você estivesse usando um IDE nativo de contêiner como o GNOME Builder , que é enviado como Flatpak, e configurasse automaticamente um contêiner para construir e executar o software em que está trabalhando, então não precisaria do Toolbox de forma alguma.

No entanto, nem todo mundo usa o GNOME Builder, e os IDEs mais populares, como o Visual Studio Code, não são nativos de contêiner assim. Conseqüentemente, Toolbox.

@debarshiray Obrigado pela resposta atenciosa e completa. O exemplo que dei acima não era para aplicativos gráficos que podem ser cobertos pelo Flatpak. Eu dei o exemplo de fazer desenvolvimento em Node.js. Recentemente, houve um malware real na cadeia de dependências do Node.js que poderia roubar de uma carteira de criptografia local. As chaves SSH podem ser roubadas com a mesma facilidade. Embora o README diga que o projeto visa os desenvolvedores, o compartilhamento com contêineres por padrão não faz nada para proteger os desenvolvedores desse tipo de ataque.

O Toolbox não oferece segurança contra roubo de arquivos pessoais ao fazer o desenvolvimento CLI com quaisquer dependências não confiáveis. Dada a complexidade do software de código aberto moderno, é provável que haja algumas partes da árvore de dependências nas quais não se deve confiar.

Acho que o README atual é enganoso: Executar "totalmente sem privilégios em um contêiner" soa como segurança, mas é apenas um teatro de segurança - todos os arquivos pessoais podem ser acessados ​​no contêiner. Acima, você esclarece que o Toolbox não pretende fazer reivindicações sobre segurança. Acho que seria uma declaração útil incluir no README para esclarecer que, apesar do uso de contêineres, esta é uma ferramenta por conveniência, não por segurança.

@debarshiray Obrigado pela resposta atenciosa e completa. O exemplo que dei
acima não era para aplicativos gráficos que poderiam ser cobertos pelo Flatpak. Eu dei o
exemplo de fazer o desenvolvimento Node.js. Recentemente, houve malware real no Node.js
cadeia de dependência que pode roubar de uma carteira criptografada local. Chaves SSH podem ser roubadas
com a mesma facilidade. Embora o README diga que o projeto visa os desenvolvedores, o
share-with-containers-by-default não faz nada para proteger os desenvolvedores desse tipo de ataque.

Sim, no momento o Toolbox apenas tenta reproduzir o ambiente tradicional baseado em pacote dentro de um sistema operacional baseado em imagem.

Acho que o README atual é enganoso: executando "totalmente sem privilégios em um contêiner"
soa como segurança, mas é apenas um teatro de segurança - todos os arquivos pessoais podem ser acessados ​​em
o contêiner. Acima, você esclarece que o Toolbox não pretende fazer reivindicações sobre segurança.
Acho que seria uma declaração útil para incluir no README para esclarecer que apesar de
o uso de contêineres, esta é uma ferramenta de conveniência, não de segurança.

Commit c047659c1d85ca982374da5c58ee7a24ba3847bd é onde essa linha foi adicionada. Acredito que @cgwalters pretendia dizer que você só tem acesso ao seu próprio UID dentro de um contêiner de caixa de ferramentas e que a raiz real (ou seja, UID 0 no host) não está envolvida ou disponível para você.

Eu também tenho o mesmo problema. Instalei o Silverblue com a esperança de poder executar um software no qual não posso confiar inteiramente, sem ter que me preocupar se ele roubar minhas chaves SSH e outras informações confidenciais.

A percepção de que a caixa de ferramentas não me permite fazer isso foi uma grande decepção e me levou a reconsiderar o uso do Silverblue para começar. Pessoalmente, não me importo com a instalação do sistema operacional principal. Sempre posso reinstalar isso. As informações que desejo manter realmente segregadas estão localizadas em meu diretório inicial.

Seria possível especificar com alguma granularidade maior precisamente quais partes do diretório inicial são compartilhadas? Se alguém pudesse colocar na lista de permissões apenas os diretórios necessários para a caixa de ferramentas (provavelmente aqueles relacionados à configuração da área de trabalho, etc.), muitos problemas seriam resolvidos.

Agora, estou perfeitamente ciente dos problemas de segurança. Como uso o sistema operacional Qubes há vários anos, o problema de isolamento é difícil. Mesmo que você proteja o diretório inicial, isso não será suficiente, pois um programa em execução dentro de um contêiner sempre pode tirar proveito de outros meios de comunicação entre os contêineres, como a área de transferência. Estou ciente disso e estou disposto a aceitar alguns desses riscos em troca da conveniência de algo como uma caixa de ferramentas em comparação com uma instalação completa do Qubes.

Uma solução alternativa é publicada aqui .

A solução alternativa explora o fato de que toolbox é implementado como um script bash que faz referência à variável de ambiente $HOME em todos os casos em que o caminho de /home/user precisa ser pesquisado. Portanto, definindo a variável de ambiente $HOME para uma chamada específica para toolbox faz com que um diretório diferente de seu diretório home inteiro cheio de arquivos pessoais valiosos seja compartilhado com um contêiner potencialmente não confiável.

Com base nisso, parece que você pode compartilhar um diretório vazio que contém apenas a configuração da caixa de ferramentas, iniciando a caixa de ferramentas com um invólucro semelhante a este:

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

Se este script fosse denominado toolbox e colocado em seu $ PATH antes do sistema toolbox , então parece que resolveria essa preocupação. Esta solução não foi testada.

Este recurso agora está funcionando na bifurcação tlbx : https://gitlab.com/uppercat/tlbx/issues/3

Eu também tenho o mesmo problema. Instalei o Silverblue com a esperança de ser capaz de
executar software no qual posso não confiar inteiramente, sem ter que me preocupar se ele roubar meu SSH
chaves e outras informações confidenciais.

Umm ... isso parece enganoso. Se você deseja executar software não confiável como um usuário, o Flatpak já reduz suas preocupações com a perda de informações confidenciais. Se você deseja ambientes de desenvolvimento isolados, isso é outra coisa.

Além disso, nada disso é específico do Silverblue de forma alguma. Os problemas existem há décadas e as soluções não são específicas do Silverblue - elas também funcionam em sistemas operacionais baseados em pacotes tradicionais.

A solução alternativa explora o fato de que toolbox é implementado como um script bash que
faz referência à variável de ambiente $HOME em todos os casos em que o caminho de /home/user
precisa ser pesquisado. Portanto, definindo a variável de ambiente $HOME para um determinado
chamar toolbox faz com que um diretório diferente de todo o seu diretório inicial esteja cheio de informações valiosas
arquivos pessoais a serem compartilhados com um contêiner potencialmente não confiável.

Sim, é um hack bacana. :)

No entanto, o objetivo principal do projeto Toolbox é permitir a configuração de uma ampla variedade de ambientes de desenvolvimento em sistemas operacionais baseados em imagens (principalmente baseados em OSTree) com aproximadamente a mesma quantidade de esforço que é necessário em suas contrapartes baseadas em pacotes. Tornar esses ambientes de desenvolvimento mais seguros é definitivamente um desejo válido, mas não é algo que esteja na lista de tarefas imediata, porque o problema não é novo e existe desde sempre.

Além disso, o Silverblue não é necessariamente sobre segurança. Eu vejo isso mais como uma melhoria na estabilidade e robustez do sistema operacional. No entanto, ele incentiva o uso de Flatpaks, portanto, nesse sentido, melhora indiretamente a segurança.

Portanto, há valor em garantir a paridade de recursos com distribuições Linux baseadas em pacote, mesmo que retenha alguns dos problemas existentes. Resolver alguns problemas e tornar as soluções acessíveis à base de usuários existente é melhor do que não resolver nada. :)

Vou encerrar este problema para que a lista de problemas em aberto não saia do controle e continue a refletir aproximadamente os itens que estão na lista de tarefas atuais. No entanto, ele ainda estará disponível para referência futura.

Eu concordo que nosso README.md deve ser mais fácil de ler, no entanto.

Hmm, eu não entendo esse argumento. Só porque um problema é antigo e existe desde sempre, não o resolve ?? Esse não é um bom ponto de vista, IMHO.
E, como você disse, o flatpak faz isso: melhora passo a passo a segurança e isola os aplicativos. Eles também não disseram "hmm, nós enviamos aplicativos como pacotes rpm para sempre, por que deveríamos resolver esse problema?", Eles apenas o resolveram.

Não vejo razão para que a caixa de ferramentas não deva pelo menos isolar também o diretório inicial. Então, acho que a discussão pode continuar em https://github.com/containers/toolbox/issues/348 de qualquer maneira.

Acho que os contribuidores e mantenedores da caixa de ferramentas estão interpretando esse tópico como uma crítica à ideia e ao trabalho que é colocado no projeto. Acho que deve ser visto como um recurso exigido por muitas pessoas entusiasmadas com a ideia. Eu não percebo a resistência de trabalhar em um recurso que permite montar um diretório de trabalho diferente de $ HOME. É um recurso que pode melhorar muito a funcionalidade e o caso de uso, o que também aumentará a adoção e o interesse.

Fui eu quem sugeriu alterar a variável $ HOME em # 348. É uma solução hacky porque causa problemas quando você deseja trabalhar com dois contêineres múltiplos com diretórios $ HOME diferentes. Meu medo é que até mesmo isso não funcione quando a caixa de ferramentas for reescrita com go.

Muitas pessoas estão pedindo esse recurso e ele se tornou uma barreira de entrada para muitas pessoas adotar caixas de ferramentas, rpm-ostree e silverblue. Mesmo que não se trate de segurança, é um recurso que vai abrir muitas possibilidades para trabalhar com caixas de ferramentas.

Estou disposto a ajudar nessa questão se puder e acho que outras pessoas também estarão dispostas. Espero que esse recurso não se torne um ponto de discórdia e seja deixado de fora em versões futuras da caixa de ferramentas. É, em minha opinião, a única coisa que falta nele atualmente. Seria como tirar um dnf em uma maratona por ter desistido dos últimos 10 metros. (trocadilho intencional :))

Foi um quebra-negócio para mim. Desisti da caixa de ferramentas e do Silverblue depois
encontrar essa falha.

Só porque um problema é antigo e existe desde sempre,
só não resolve ?? Esse não é um bom ponto de vista, IMHO.

Não ter algo na lista imediata de tarefas não é a mesma coisa que não resolver . Existe uma coisa chamada prioridade .

E como você disse, o flatpak faz isso: passo a passo, melhora a segurança e
isola aplicativos. Eles também não disseram "hmm, enviamos os aplicativos como
pacotes rpm para sempre, por que devemos resolver esse problema? ", eles acabaram de resolver
resolva isso.

Eu amo o seu uso da palavra eles .

Ok, legal, então se eu interpretar corretamente, isso ainda pode ser uma ideia para o futuro, mas não em sua "lista imediata de tarefas"? (embora eu ache que seja fácil de implementar, especialmente se você puder escolher alguns patches de um fork ) *

Em caso afirmativo, talvez apenas mantenha este problema aberto e marque-o como "procura-se ajuda" - embora você realmente não precise de ajuda, não sei ... o que o impede de implementar isso? Acho que você só precisa dizer que aceita os RPs sobre esse assunto e ele será implementado.
Não vejo nada impedindo você de fazer isso - e você ainda pode obter paridade de recursos ou algo assim ... é realmente apenas um recurso secundário. :pensamento:

* Sim, eu vejo e sei que isso foi reescrito no Go agora, mas talvez isso ainda ajude ou então - não sei. Pelo menos demonstra que é fácil de implementar.

Roubando esse problema um pouco aqui, caso algum dos participantes queira conferir e dar feedback sobre meu protótipo em https://gitlab.com/bkhl/etui

É uma alternativa ao Toolbox para quando você deseja um contêiner de desenvolvimento mais restrito.

@bkhl Obrigado! Marcado como favorito.