Engordamento do sistema por snap e flatpak

Wiltzer
(usa Outra)

Enviado em 18/11/2020 - 11:00h

Lembrei que existe um site que "detona" o flatpak e mostra suas falhas e como a equipe da RHEL trata isso, chama-se https://flatkill.org/
Lembro também haver um outro fazendo o mesmo o snap, só não recordo o nome. No site do flatpak diz, traduzido:

removido
(usa Nenhuma)

Enviado em 18/11/2020 - 11:02h

Por que não usar? Por que usar? Usei ioiô

removido
(usa Nenhuma)

Enviado em 18/11/2020 - 11:20h

Foi exatamente o que eu disse em um outro tópico sobre snap/flatpak; a solução não pode ser pior que o problema.

Falando em segurança, olha só:

https://www.omgubuntu.co.uk/2018/05/ubuntu-snap-malware

Giovanni_Menezes
(usa Devuan)

Enviado em 18/11/2020 - 11:37h

Cara, agora eu fiquei surpreso!

Eu sabia que o snap era uma B@$#4, o Leandro Ramos até fez um vídeo a respeito da distribuição do snap no site e a equipe do mint fez suas observações a respeito, mas essa do flatpak, eu não sabia que estava assim, imaginei que estaria ao menos com o mínimo de seriedade!

QUE RELAXO!

É isso que querem empurrar nas máquinas das pessoas ?! bem que cheirava mal essa iniciativa de formato único de distribuição de software.

removido
(usa Nenhuma)

Enviado em 18/11/2020 - 11:43h

A parte mais crítica dessa salada toda. Também não sabia que a coisa estava tão feia assim...

Único flatpak que eu tenho instalado aqui é o OpenRA, um jogo de estratégia, que não tem versão deb no site oficial.

Desse jeito ai, vou pensar seriamente em remover o flatpak da máquina e a começar a empacotar meus próprios debs!

ricardogroetaers
(usa Linux Mint)

Enviado em 18/11/2020 - 22:55h

Dúvida:
Isso já não existe fora do snaps e flatpaks?
Eu não tenho snaps nem flatpaks.
Meu ambiente de trabalho é o Xfce mas o aplicativo para Kde diz que é Kde plasma.
Mistério! ... ou os componentes necessários para execução dos programas coexistem harmonicamente?

Wiltzer
(usa Outra)

Enviado em 19/11/2020 - 01:47h

E olha que essa noticia sobre o flatpak foi de 1 a 2 anos atrás, o cara escreveu uma atualização, deste ano 2020, que pode ser lida aqui (não a traduzi) https://flatkill.org/2020/
No fim, não teve lá grandes mudanças. Mas vale a pena checar.

Em relação ao snap, isso não me assusta tanto, afinal, qualquer um [teoricamente] pode criar um snap e o crivo de segurança é bem baixo. Inclusive, a própria Canonical já disse que se preocupa mais com quem (empacota, cria, pública o snap) do que com o conteúdo em si do que foi empacotado. Ou seja, o código que corre ali não é o foco.

Veja em https://snapcraft.io/blog/trust-and-security-in-the-snap-store

Em um dos paragrafos do artigo acima, diz:

Ao meu ver, tal conduta é problemática.

Wiltzer
(usa Outra)

Enviado em 19/11/2020 - 01:52h

Não cheguei a ver esse vídeo dele, depois vou checar (se vi, já não lembro). Só sei que não é de hoje que estão caindo matando no Mint e até deixando de recomendar, justamente por causa da posição dele em relação aos snaps.
Em 2020, pelo que diz a atualização no site, muita coisa continua na mesma, veja mais em https://flatkill.org/2020/

Eu também pensava isso em relação ao flatpak, ainda mais por ser algo 100% aberto e da comunidade, achava que os problemas fossem pequenos, mas é mais do mesmo.

Wiltzer
(usa Outra)

Enviado em 19/11/2020 - 01:57h

Houve uma atualização em 2020 desses problemas, postei o link nos comentários acima, alguns foram melhorados e outros continuam na mesma. Mas ainda assim, mostra que é algo feito as coxas e que a preocupação com segurança, não é algo trivial. A pouco, em relação aos snaps, tava tendo reclamação de empresas em relação a criação de snaps de apps proprietários com modificações sem autorização do criador, se não em engano foi o WPS Office que criaram uma versão sem conexão com sistema cloud deles (ou algo do tipo). Como qualquer um pode criar um snap e o crivo de segurança da Canonical não é lá grandes coisas, qualquer app entra lá facilmente.

Wiltzer
(usa Outra)

Enviado em 19/11/2020 - 02:28h

Tradução da página https://flatkill.org/2020/

Flatpak - um pesadelo de segurança - 2 anos depois

Dois anos atrás, escrevi sobre o então fortemente promovido Flatpak, autoproclamado "Futuro dos Aplicativos no Linux". O artigo fez crítica aos seguintes três fluxos principais em Flatpak:

1. A maioria dos aplicativos tem acesso total ao sistema host, mas os usuários são induzidos a acreditar que os aplicativos estão em sandbox;
2. Os runtimes do flatpak não recebem atualizações de segurança;
3. Flatpak quebra muitos aspectos da integração do desktop.

Então, vamos ver como os desenvolvedores Flatpak trataram dessas questões fundamentais.

O sandbox CONTINUA SENDO uma mentira
Quase todos os aplicativos populares no Flathub ainda vêm com permissões filesystem=host ou filesystem=home, em outras palavras, acesso de escrita ao diretório home do usuário (e mais), portanto, tudo o que é necessário para escapar da sandbox é o trivial echo baixar_e_executar_o_mal >> ~/.bashrc. É só isso!

Os aplicativos mais populares no Flathub ainda sofrem com isso - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC ainda não estão em sandbox.

E, de fato, os usuários ainda são enganados pelo ícone azul "sandbox" reconfortante. Dois anos não são suficientes para adicionar um aviso de que um aplicativo não está em sandbox se vier com permissões perigosas (como acesso total ao seu diretório home)? É sério?

Imagem: https://flatkill.org/2020/sandboxlie.png

Os aplicativos e tempos de execução Flatpak AINDA contêm falhas de segurança conhecidas há muito tempo

Levei cerca de 20 minutos para encontrar a primeira vulnerabilidade em um aplicativo Flathub com acesso total ao host e nem me preocupei em usar um scanner de vulnerabilidade.
Um exemplo perfeito é CVE-2019-17498 com exploit público disponível por cerca de 8 meses. O primeiro aplicativo no Flathub que descobri que usa a biblioteca libssh2 é o Gitg e, de fato, é fornecido com libssh2 sem patch.

Mas é apenas uma aplicação? Vejamos os runtimes oficiais no "coração" do Flatpak (org.freedesktop.Platform and org.gnome.Platform 3.36 - no momento da escrita, usados pela maioria dos aplicativos no Flathub). A primeira dependência vulnerável sem patch que encontrei no runtime oficial é o ffmpeg na versão 4.2.1 sem patches de segurança portados, CVE-2020-12284.

Recentemente me deparei com um artigo de 2011 que deu início ao que hoje é conhecido como flatpak, nas palavras do fundador do projeto:
"Outro problema são as atualizações de segurança (ou correção de bug) em bibliotecas agrupadas. Com bibliotecas agrupadas, é muito mais difícil atualizar uma única biblioteca, pois você precisa encontrar e atualizar cada aplicativo que a usa. Melhor suporte de ferramentas e atualização pode diminuir o impacto de isso, mas não eliminá-lo completamente."
https://people.gnome.org/~alexl/glick2

Depois de ler isso, não é nenhuma surpresa que o flatpak ainda sofre dos mesmos problemas de segurança de 2 anos atrás, porque os desenvolvedores do flatpak sabiam desses problemas desde o início.

Explorações de root locais NÃO são mais consideradas um problema menor!
Ótimo! Dois anos atrás, eu escrevi sobre uma exploração trivial de root local usando flatpak para instalar binários suid (CVE-2017-9780) e como isso foi minimizado pelos desenvolvedores de Flatpak como um pequeno problema de segurança aqui. Estou feliz em ver que pelo menos a atitude em relação aos exploits de root locais mudou e hoje os exploits de root locais são considerados de alta severidade.

Integração com o desktop
As fontes do sistema e do usuário agora estão disponíveis para aplicativos flatpak e as configurações básicas de renderização de fontes também são respeitadas; no entanto, não espere alterações em /etc/fonts, normalmente configurando uma fonte substituta adequada para caracteres CJK, para funcionar com o flatpak. Os aplicativos KDE no flatpak ainda estão ignorando temas, fontes e configurações de ícones (testados com Qt5ct). Os aplicativos instalados a partir das fontes de distribuição não apresentam esses problemas, é claro. Uma captura de tela rápida para demonstrar = https://flatkill.org/2020/desktopbrokenation.mp4

Mais importante, fcitx, o IME para chinês ainda está quebrado - já se passaram 2 anos. Aqui está o problema que vinculei há 2 anos - especialmente interessante é o seguinte comentário diretamente do desenvolvedor da fcitx:
"Porque o módulo fcitx im em flatpak é de 4.2.97 e usa um caminho de objeto dbus diferente. Ele precisa ser a mesma versão do fcitx em seu host."

Portanto, preciso executar vários daemons fcitx na minha área de trabalho e alternar entre eles conforme alterno os aplicativos flatpak, dependendo de quais bibliotecas fcitx estão agrupadas com esse aplicativo ou talvez no futuro das aplicações Linux não seja mais possível digitar em chinês e está tudo bem?
Embora a abordagem "agrupar tudo" tenha se mostrado muito útil em servidores, ela claramente não funciona para aplicativos de desktop, vamos continuar vinculando as bibliotecas do sistema em aplicativos de desktop (e usar as bibliotecas agrupadas apenas como fallback) para evitar a introdução de todos esses problemas no desktop Linux.

removido
(usa Nenhuma)

Enviado em 19/11/2020 - 08:33h

Onde você leu que eu disse que não existe compartilhamento de runtimes fora de Snaps e Flatpaks?
Eu não disse o que você entendeu.
Respondi a um comentário que dizia que não tem reaproveitamento de bibliotecas nesses sistemas.

Sei muito bem as vantagens de usar DEB/RPM. E sei muito bem que dá para instalar qualquer software escrito para Linux em qualquer distribuição, independente de qual interface gráfica o usuário tem.
Também sei que é possível trocar o papel de parede sem precisar baixar um tema verde que vem com uma ISO com mais de 1 GB de tamanho.
Posso até transformar qualquer Ubuntu em um Linux Mint sem a necessidade de baixar o próprio Linux Mint.

maurixnovatrento
(usa Slackware)

Enviado em 19/11/2020 - 11:12h

Até aí eu já não sei, mas só sei dizer que já vi em algum lugar escrito que não proporcionam boa integração. Isso é algo que não me agrada muito.

___________________________________________________________

Conhecimento não se Leva para o Túmulo.

https://github.com/MauricioFerrari-NovaTrento