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 还没有评估数据。