AppImage / AppImage/AppImageKit

Investigate AppArmor

オープン
#452 コメント 13 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
言語のデータがありません
スター
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 はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。