AppImage / AppImage/AppImageKit
Investigate AppArmor
- 主要言語
- 言語のデータがありません
- スター
- 9.4k
- フォーク
- 588
- PR マージ指標
- PR 指標を取得中
説明
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!
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
評価
この issue はまだ評価されていません。