AppImage / AppImage/AppImageKit

Investigate AppArmor

Open
#452 13 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.