AppImage / AppImage/AppImageKit
Investigate AppArmor
- Dominant language
- No language data
- Stars
- 9.4k
- Forks
- 588
- PR merge metrics
- PR metrics pending
Description
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!
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.