AppImage / AppImage/AppImageKit

Investigate AppArmor

Aberta
#452 13 comentários 0 reações 0 responsáveis Ver no GitHub
Linguagem predominante
Sem dados de linguagem
Estrelas
9.4k
Forks
588
Métricas de merge de PRs
Métricas de PR pendentes

Descrição

In [this GUADEC talk](https://www.youtube.com/watch?v=SPr--u4n8Xo&feature=youtu.be&t=1268) @sysrich describes the "crazy insecure lunacy of AppImage".

So, here is our plan:
- By default, AppImages lack the executable bit
- With the optional `appimaged` daemon installed (which distributions could opt to do in their default installation), check for embedded signatures
- Depending on the trust level of the signature, three things could happen a) the AppImage gets integrated into the system and is made fully executable without a sandbox (e.g., this could be configured for AppImages signed with the distribution's key), b) the AppImage gets integrated into the system and is sandboxed with a moderately conservative profile (this could be done for other signed AppImages) c) the user sees a warning that the AppImage is not signed (similar to what macOS does in the default configuration) and that this app wants to do a b c d e f g (depending on what its Firejail/AppArmor profile defines)
- Establish a crowd-sourced GPG-based "web of trust"
- [AppImageHub](https://github.com/AppImage/AppImageHub) will display information about signatures and the level of trust

We could do this by
1. Integrating firejail and signature checking into `appimaged`, or
2. as @sysrich suggests, use AppArmor

1 has the advantage that it works today, 2 has possibly other advantages that need to be investigated.

2 is apparently dependent on some patches that need to be upstreamed by Canonical.

Any thoughts, insights, discussions, contributions welcome!

Guia de contribuição

Nenhum guia de contribuição indexado para este repositório

Avaliação

Esta issue ainda não foi avaliada.

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.