[ZehMatt]

Instead of the submodule it now uses nuget for the prebuilt binaries for all platforms using CEF version 154.0.34, Avalonia seems to reference the same binaries so I think its a safe bet on them.

I gave the whole CEF process its own executable instead of round-tripping over Source.Launcher, CEF sandboxing is still turned off but this also would never work unless we run it through its bootstrapper but I think we don't really need it, the sub process now runs with some mitigations such as setting the access token to the lowest on Windows, see ProcessLockdown.cs. In the future we should compile this process with Native AOT which allows to enable some extra security features like ProcessDynamicCodePolicy

For Linux we can actually apply more aggressive restrictions like blacklisting syscalls and use Landlock which isolates file access to only places we accept, I haven't done that yet as I need to fix my dual boot setup, maybe someone else can apply and test it.

[marchc1]

I would rather use the Chromium sandbox from a standpoint of what is typically (and what Garry's Mod has) done, however I think this is acceptable. ProcessDynamicCodePolicy would break the V8 JIT in the CEF process.

Besides, this also makes CEF easier for us to update since it's all from Nuget and done for us, so any future vulnerabilities relating to CEF can be (hopefully) easily patched, although we'll have to see if this package has appropriate response times (and if not maybe we have to spin something up, but either way this would make the process of updating easier for us)