I've tried both Dolphin and KMozillaHelper(Firefox) and they escape their sandboxes through KDE's services. This is probably the fault of Xorg too but KDE should NOT share the FS like this.
There are many ways to bring the dedicated source files to a way that many can believe they are real. If they are not real then they need to be deleted from the base file list rather than get a new one. Thanks for the efforts!
Please when reporting bugs add the following information: - Exact steps to reproduce - What you expect to see - What you see instead 'KDE' is a community, and you have to be more clear what type of KDE software you are using and what issue you get exactly.
If you can provide the information requested in comment #2, please add it.
I don't know what you've failed to understand. KDE services(like KIO) help programs escape the sandbox. How to reproduce? Sandbox a KDE app and try to select files with KDE's file dialog. If the sandboxed app's *directory structure matches* with yours then the app will get its hand on the FS. firefox with gnome's file chooser doesn't escape the sandbox. firefox-kde does. The rest of the KDE apps can't be properly sandboxed either. See this reddit thread when someone else also experienced the same: https://www.reddit.com/r/kde/comments/7pl325/how_does_kio_work/
> Sandbox a KDE app How? Please add exact steps to reproduce. Assuming you are using Linux, there are several tools to restrict file system access, and we need more information which setup you are using, and why it fails with KDE applications but not with other applications.
By using either firejail or flatpak(the backend is bubblewrap) - these are the most popular sandboxing solutions. I guess KIO provides a global file dialog for every X app and if an application connects to X(and KDE) KIO can leak files. For example: I fake a home dir with `firejail --private=~/FF_jail firefox -no-remote` then I have a 'Documents' folder both in the sandbox and in my home dir and if I've firefox-kde - which uses KDE's file dialog instead of gnome's then KIO will show me MY home dir - and if the 'Documents' folder is present in both then the sandbox will be able to read the content from outside. Another example: If I open dolphin with `firejail --private=~/dj dolphin` then it'll be able to access almost everything. I'd try okular with firejail but it crashes with: " mprotect failed in ExecutableAllocator::makeExecutable: Access denied *** stack smashing detected ***: <unknown> terminated "
Another thing: I've used the experimental KDE+flatpak repo to try the flatpakked KDE apps. I haven't tried them today.
Reassigning to KIO developers for inspection.
As long as there is access to D-Bus, not your sandboxed application, but the kdeinit5 process running outside the sandbox forks the KIO slave, which leads to the issue you described. To work around this, deny the firejail sandbox access to the D-Bus session bus, for example by passing --blacklist=/run/user/$UID/bus on the command line. Then open a file dialog, and you see that there is no escape from the sandbox any more. If you inspect this firejail sandbox in another terminal with $ firejail --tree you'll find that the KIO slave now is running inside the sandbox, as a child process of your KDE app. Anyways, this is only part of the picture. To sandbox applications in rich desktop environments like KDE or Gnome, you should *always* deny access to the D-Bus session bus. From the perspective of sandboxing, D-Bus is a nightmare, and Gnome doesn't really expose less attack surface than KDE.
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!