profiles: replace private-opt with whitelist & document private-opt issues

[glitsj16]

private-opt breaks file-copy-limit, use a whitelist instead of draining RAM
cfr. #5307

This PR streamlines the comment and does the relevant whitelisting in /opt.

[kmk3]

(Adding a NAK mostly due to the duplication)

Misc: It seems like a good idea to avoid private-opt for very heavy programs
(like electron-based ones), but I'm not sure about never using it on upstream
profiles (I might expand on this later).

[glitsj16]

Misc: It seems like a good idea to avoid private-opt for very heavy programs
(like electron-based ones), but I'm not sure about never using it on upstream
profiles (I might expand on this later).

@kmk3 Thanks for your review. I had similar doubts about discarding private-opt across the board. True, for less sizable applications the RAM overhead looks tolerable. I'm just not sure where we should draw the line. IMO it's rather likely that users will have way more than one sandbox running in parallel, and things start to add up. I should have elaborated on my reasoning in this context. When I compared the sandbox gains of having private-opt on top of whitelisting the relevant path(s) under /opt I just couldn't see all that much extra hardening to be honest. Looking forward to your insights/arguments.

[kmk3]

Sorry for the delay, I couldn't get to this earlier.

@glitsj16 on Sep 26:

Thanks for your review. I had similar doubts about discarding private-opt
across the board. True, for less sizable applications the RAM overhead looks
tolerable. I'm just not sure where we should draw the line. IMO it's rather
likely that users will have way more than one sandbox running in parallel,
and things start to add up. I should have elaborated on my reasoning in this
context. When I compared the sandbox gains of having private-opt on top of
whitelisting the relevant path(s) under /opt I just couldn't see all that
much extra hardening to be honest.

👍

Looking forward to your insights/arguments.

Not much insight, just this:

Pros:

• Programs in /opt tend to be heavy, so less RAM would be wasted
• Always using whitelist /opt/dir upstream would be simpler

Cons:

• Programs in /opt tend to be complex and proprietary, so a bit of extra
  security might be useful

I mostly just wanted to give it some consideration, but indeed it's hard to
draw a line and I'm also not sure how much it really matters.

@glitsj16 on Sep 27:

Did some extra research on the size of the non-electron apps. I implemented
your suggestions, including a warning note to firejail(1). Kept private-opt
for enpass (~85MB), mate-dictionary (<20MB), minecraft-launcher (~1.6MB) and
ppsspp (~44MB). The only app I couldn't check: xmr-stak (FTBFS on my Arch
Linux box). I returned it to the functional state it had prior to this PR.

Sounds good to me.

Fixed

[kmk3]

Main force-push changes:

• Removed whitelist when there's private-opt for consistency
• Edited/added more to the docs

It currently looks good to me.

Thoughts on the changes?

[glitsj16]

@kmk3

Sorry for the delay, I couldn't get to this earlier.

That's quite allright, no worries.

Thoughts on the changes?

I'm okay with your changes. Like you mentioned, there will always be pros & cons to private-opt and users should be aware of the RAM-ifications. Not much more we can do here IMO.

Thanks again for your efforts and opinions!