D8532: [WIP] Restrict file extractor with Seccomp

[David Kahles]

davidk added a comment.
Restricted Application edited subscribers, added: kde-frameworks-devel; removed: Frameworks.


  I was asked in private about the current state of libseccomp integration and why there was no progress in a long time.
  The current state is, that I have implemented seccomp support in kfilemetadata using this API:
  
    bool setProcessReadOnly(uint32_t defaultAction, std::vector<SeccompFilter> addionalWhitelist)
  
  But there are two blockers, related to external plugins:
  
  - External plugins based on interpreters like python/lua/perl etc. need a huge whitelist. This is problematic as I want to keep the list of allowed syscalls as small as possible (the list would be huge). Additionally, it would be difficult to get a list of all needed syscalls. Thus, we would break many external plugins.
  - Baloo is basically unmaintained. Thus, if something breaks, fixing it should be as easy as possible. But what if QT requires a new syscall and thus, the tests (and deployments) are failing? We need a way to know which syscall failed. This works for kfilemetadata plugins, but not for external plugins (because they are separate processes). The only way I can image, would be running the whole test with strace.
  
  So, if anyone is willing to continue this work, I would be happy to share my current state.
  Otherwise, if everyone agrees that we don't care about external plugins (users of external plugins can disable Seccomp support with an environment variable), I can finish the patches.

REPOSITORY
  R293 Baloo

REVISION DETAIL
  https://phabricator.kde.org/D8532

To: davidk, apol, ossi
Cc: kde-frameworks-devel, michaelh, #baloo, detlefe, ngraham, nicolasfella, ashaposhnikov, astippich, spoorun, bruns, abrahams, #frameworks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180709/a8d1a865/attachment.html>