Proposal for a static way to "prove" an AppImage has capabilities such as sandboxes

This issue document a discussion with @TheAssassin regarding how to provide a
way to securely prove that an AppImage runs in a FireJail sandbox before
execution with and without AppImageLauncher.

## What is the issue

Flatpak and Snap both enforce sandboxing but AppImage doesn't. It isn't a good
way to sell this technology if the user perceive it as less secure. On the
other hand, Flatpak/Snap are much larger and integrated stacks that try to fix
too many problem while AppImage try to solve the bundling and nothing else.

That doesn't say AppImage cannot be secure. In fact, many already use external
sandbox projects to provide some level of extra security. One major downside of
such AppImages is that there is little way to know ahead of time:

* If there is sandboxing
* If the sandbox is actually used
* What is the profile
* Has the sandbox been altered to render it a no-op (or worst)
* Will it be equally secure if I don't have FireJail installed

## Where can it be solved

A solution to this problem and be provided by a combination of improvements to
appimagetool to ensure a sandbox is used. This solution has to be used in 2
main places:

* When the user downloads the AppImage, he/she/it has to be told whether or not
there is guaranteed sandboxing.
* If AppImageLauncher is installed, it should display this information
* If the Dolphin file manager is used, it should add a mark to sandboxed
AppImages
* If the KDE Store was to distribute AppImages, it should also provide this
information

## What does this solution does **not** attempt to solve

In the Unix philosophy, we have little tools that solve a problem and only one
problem. This solution doesn't attempt to prove that:

* FireJail is secure
* The profile is actually restricted enough
* The application contains malware or crytpo currency miner.
* appimagetool, the runtime etc. are perfect bug free

## Enough talking, what's your damn idea?

### When creating "SandboxedAppImageTool"

1) Create a signed AppRun or other kind of entry point known and proven to start
FireJail (probably the runtime is more suitable for that)
2) Provide a FALLBACK signed FireJail binary. Maybe from a trusted distribution.
3) Sign that FireJail as a known unmodified version so the AppImage creator
cannot weaken it
4) Ship that in "SandboxedAppImageTool" and enforce that the profile has to
be provided (first we need to provide a standardized way to distribute firejail profiles within AppImages)

### When creating an AppImage

1) Provide a profile with a standardized name in a standardized place
2) Provide a program entry point within the jail, entry points outside are
prohibited

### When upload an AppImage to a "store"

1) Inspect (mount or extract or just read the embedded filesystem image) the AppImage
2) Check that the AppRun (or else) and FireJail signature match the known one
3) Extract the profile and parse it
4) Decide if the AppImage has sandboxing based on that
4.1) Warn about AppImage with old FireJail with known CVE

### When the user without AppImageLauncher and/or without FireJail get an AppImage

1) Download from a source you trust
2) See that this source says the AppImage provide sandboxing and read the
profile (or trust them to validate it's secure)
3) Run it (with the fallback FireJail if you have none installed)

### When you have AppImageLauncher

1) Get an AppImage from a wider range of source
2) See in your Dolphin it has the Jail watermark
3) See the AppImageLauncher popup saying that there is sandboxing with an option
to see the profile.
4) Decide if you want to use it

## What are the problems with this

Someone will need to get and keep a certificate to sign the "trusted"
runtime and firejail. The AppImage team is unsure whether they can provide that.

It solves a tiny part of the wider problem regarding sandboxing. It doesn't
provide a DBus proxy, doesn't manage overlays, no X11 firewall. Getting such
capability could be implemented in a similar way, but isn't part of this
suggestion.

## Why do you still think it's necessary

Because "linting" and "static analysis" are one of the only way to add feature
without bloating the AppImage project with more thing. It should still
concentrate on bundling and let other services to handle their part. You still
have a semi centralized way to prove such services are enabled and this is
what I propose.