D8532: [WIP] Restrict file extractor with Seccomp

ngraham added a comment. Hmm, looks like @davidk has not been active in almost a year, so I suspect someone else may need to commandeer this... REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi, #frameworks, smithjd, bruns Cc: fvogt,

D8532: [WIP] Restrict file extractor with Seccomp

fvogt added a comment. In D8532#478224 , @bruns wrote: > I totally agree with fvogt here - the extractors should just receive a readonly file descriptor. > > For this, there are several steps required: > > 1. let the extractors work with

D8532: [WIP] Restrict file extractor with Seccomp

bruns added a comment. I totally agree with fvogt here - the extractors should just receive a readonly file descriptor. For this, there are several steps required: 1. let the extractors work with file descriptors (KFileMetaData) 2. make sure the extractor plugins are fully

D8532: [WIP] Restrict file extractor with Seccomp

ngraham edited the summary of this revision. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi, #frameworks, smithjd, bruns Cc: fvogt, mgallien, kde-frameworks-devel, michaelh, #baloo, detlefe, ngraham, nicolasfella, LeGast00n, domson,

D8532: [WIP] Restrict file extractor with Seccomp

ngraham added a comment. Ping! What's going on with this? REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi, #frameworks, smithjd, bruns Cc: fvogt, mgallien, kde-frameworks-devel, michaelh, #baloo, detlefe, ngraham, nicolasfella, LeGast00n,

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. Dropping one more comment, in case someone wants to give it a try: Apparmor profile transitions don't work if a seccomp filter has been installed before. This makes it probably rather difficult to integrate DrKonqi into an Apparmor policy. REPOSITORY R293 Baloo

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. In D8532#336584 , @fvogt wrote: > AFAICT this won't actually protect much - the open DBus socket is enough to execute arbitrary programs. > > The best design would be (IMO, not sure how well the current architecture

D8532: [WIP] Restrict file extractor with Seccomp

fvogt added a comment. AFAICT this won't actually protect much - the open DBus socket is enough to execute arbitrary programs. The best design would be (IMO, not sure how well the current architecture fits) to have a fully sandboxed executable which can only communicate with baloo over

D8532: [WIP] Restrict file extractor with Seccomp

mgallien added a comment. In D8532#289500 , @davidk wrote: > 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

D8532: [WIP] Restrict file extractor with Seccomp

ngraham added reviewers: Frameworks, smithjd, bruns. ngraham added a comment. +1 for something rather than nothing. No comment on the technical aspect, but I'm adding more reviewers who can hopefully help un-wedge this patch. REPOSITORY R293 Baloo REVISION DETAIL

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. I'm just an interested user and cannot comment on the question of external plugins. But before this enters a deep sleep, I wonder if at least the //current// patch should find its way into the extractors or into kfilemetadata. A whitelist is the real thing, and

D8532: [WIP] Restrict file extractor with Seccomp

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

D8532: [WIP] Restrict file extractor with Seccomp

davidk added a comment. In D8532#215476 , @michaelh wrote: > I don't know Seccomp. But as far as I understood this, the same concers apply to the `baloo_file_temp_extractor` baloo-widgets is using. Naivly I suggest to implement this

D8532: [WIP] Restrict file extractor with Seccomp

michaelh added a comment. I don't know Seccomp. But as far as I understood this, the same concers apply to the `baloo_file_temp_extractor` baloo-widgets is using. Naivly I suggest to implement this KFileMetadata because both executables are using it. I don't know if that is possible or

D8532: [WIP] Restrict file extractor with Seccomp

michaelh added a project: Baloo. michaelh added a subscriber: Baloo. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi Cc: #baloo, detlefe, ngraham, nicolasfella, #frameworks, ashaposhnikov, michaelh, spoorun, alexeymin

D8532: [WIP] Restrict file extractor with Seccomp

ossi added a comment. > But i'm not sure if thats feasible. launching subprocesses is no biggie; e.g., the kprocess test does it. if you're lucky, a few env variables will be sufficient. in the worst case, you'd need to chroot and do bind mounts or something like that, which is of

D8532: [WIP] Restrict file extractor with Seccomp

davidk added a comment. Sorry for the late reply and the slow process in general. Reallife keeps me busy... In D8532#198408 , @detlefe wrote: > A whitelist, even if it is broad, would be desirable to reduce the attack surface of the kernel,

D8532: [WIP] Restrict file extractor with Seccomp

detlefe added a comment. A whitelist, even if it is broad, would be desirable to reduce the attack surface of the kernel, and is also the way it was done for Gnome Tracker. But the concerns about maintenance remain, someone should test it regularly. Are there ways this can be automated?

D8532: [WIP] Restrict file extractor with Seccomp

davidk edited the summary of this revision. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi Cc: ngraham, nicolasfella, #frameworks, michaelh

D8532: [WIP] Restrict file extractor with Seccomp

davidk added a comment. So, are there any more opinions on the whitelist vs. blacklist topic? Personally I still prefer the blacklist as I fear regressions in the future, especially because baloo is unmaintained. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532

D8532: [WIP] Restrict file extractor with Seccomp

davidk edited the summary of this revision. davidk edited the test plan for this revision. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi Cc: ngraham, nicolasfella, #frameworks, michaelh

D8532: [WIP] Restrict file extractor with Seccomp

davidk updated this revision to Diff 26108. davidk added a comment. Update TODO items. REPOSITORY R293 Baloo CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8532?vs=21469=26108 BRANCH seccomp REVISION DETAIL https://phabricator.kde.org/D8532 AFFECTED FILES CMakeLists.txt

D8532: [WIP] Restrict file extractor with Seccomp

davidk added a comment. In https://phabricator.kde.org/D8532#175079, @ossi wrote: > you *really* should use a whitelist. it's ok if that breaks some 3rdparty extractor; you'll get a bug report which you can properly evaluate. > you could go totally overboard and assign fine-grained

D8532: [WIP] Restrict file extractor with Seccomp

ossi added a comment. you *really* should use a whitelist. it's ok if that breaks some 3rdparty extractor; you'll get a bug report which you can properly evaluate. you could go totally overboard and assign fine-grained syscall capabilities to individual extractors, but i can't really think

D8532: [WIP] Restrict file extractor with Seccomp

dfaure added reviewers: apol, ossi. REPOSITORY R293 Baloo REVISION DETAIL https://phabricator.kde.org/D8532 To: davidk, apol, ossi Cc: #frameworks

D8532: [WIP] Restrict file extractor with Seccomp

davidk created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Use Seccomp for implementing a sandbox for baloo_file_extractor This change introduces a new optional dependency on libseccomp.