Add booster profile files

[spiiroin]

Boosting sandboxed applications works by launching booster in sandbox. Such application boosters use permissions for the the application they are handling. Any additional sandboxing tweaks that are needed are handled by use of booster type specific profile files.

Signed-off-by: Simo Piiroinen simo.piiroinen@jolla.com

[Tomin1]

Just a thought, but should we have these profile files for applications separate from profile files for boosters? I application binaries and booster binaries are stored separately (/usr/bin vs. /usr/libexec/mapplaunched). Then again it might not be a real issue as apps should not be prefixed with "booster-".

I assume these booster permissions don't get dropped when the app is executed, so does this open some holes like launching apps from a sandbox? That would basically mean that until that's fixed one should be careful which sandboxed apps get boosted.

[spiiroin]

This looks fine as long as we have a plan to take care of any possible holes this might introduce.

As it is not possible to modify sandbox once it is running, applications started via boosted sandbox will always have a bit wider view to system than the same app without boosting. That just needs to be taken in account when deciding whether boosting is done or not along with other details such as increased memory use etc. That said:

• Booster related data / helper binaries under /usr remain readable, but that should not be an issue
• We could perhaps already now limit permission daemon ipc to promp + get info
• Once we have those macros available it should be possible / relatively easy to limit booster socket directory access so that boosted application has write permissions only to the socket that affects the boosted application itself

[spiiroin]

Rebased

[spiiroin]

Review commits squashed