While f67a37bc21 indicated the last remaining code could stay,
it can't because there is a launch failure of SandboxedProcessor.
This has been revealed by the changes of the previous commit,
aa03d0a4920e.
Hence, the GUI will be untouched by exile. We only sandbox
the preview generation and the indexing trough IPC.
There was an off-by-one, the SandboxedProcessor was only passed
'process', not the path to the file.
No processor was found for 'process', thus 'nothingProcessor' was
returned. Therefore, we never sandboxed (because we never had
to process anything).
The sandboxing would have failed though, because we need to launch
QCoreApplication, not QApplication.
The CLI was never affected.
Qt is usually built with Accessibility and D-Bus. If D-Bus
connections work, a bypass should be considered trivial.
If we block D-Bus, we experience quite some slowdowns in
certain contexts. That's because Qt makes D-Bus connections
for accessibility features etc. They appear to run into timeouts,
but this slows down things. Sandboxing also makes things
like showing (native) file picker dialogs harder.
Sandboxing efforts will focus on the critical paths such as
the existing Indexer sandbox and the to be implemented sandboxing
for preview generation.
We keep no_new_privs for now as chances are that this shouldn't hurt.
The indexer is quite slow with unshared network namespaces. It appears something in
Qt needs it as IPC or whatever. Seeing also dbus-related errors:
Issue: #33
So disable it for now.
SandboxedProcessor is not launched via IPCServer at this point.
The vow set is already very big and SandboxedProcessor
would require exec too.
So use exile default policy and add some path permisisons.
Once SandboxedProcessor is handled by IPC and preview generation
is also exiled separately, it has to be reevaluated whether
it makes sense for vows to return.
Albert S.