[GH-ISSUE #1599] sandbox escapes with kdeinit

gitea-mirror commented

2026-05-05 07:24:38 -06:00

Owner

Originally created by @smitsohu on GitHub (Oct 9, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1599

KDE's ubiquitous KIO makes it quite easy to escape from a Firejail sandbox. Try the following:

kubuntu@kubuntu:~$ firejail --noprofile --seccomp --blacklist=/home/kubuntu/sample.pdf 
Parent pid 11228, child pid 11229
Child process initialized in 34.96 ms
kubuntu@kubuntu:~$ kioclient exec /home/kubuntu/sample.pdf 
kbuildsycoca4 running...
kubuntu@kubuntu:~$

We blacklist a pdf file which we then successfully open with kioclient from inside the jail. In a second terminal we can see that firejail --tree doesn't list the pdf reader, it has escaped the sandbox. Also the seccomp filter is lost.

kubuntu@kubuntu:~$ firejail --tree
11020:kubuntu:firejail --noprofile --seccomp --blacklist=/home/kubuntu/sample.pdf 
  11021:kubuntu:firejail --noprofile --seccomp --blacklist=/home/kubuntu/sample.pdf 
    11023:kubuntu:/bin/bash 
11179:kubuntu:firejail --tree 

kubuntu@kubuntu:~$ ps -C okular
  PID TTY          TIME CMD
11087 ?        00:00:03 okular
kubuntu@kubuntu:~$ grep Seccomp /proc/11087/status
Seccomp:        0
kubuntu@kubuntu:~$

Probably relevant to #1594

EDIT: looking a bit further, this is getting confusing. Not all applications escape, and behavior changes over time. For example Firefox escapes on Debian Jessie Mate, but not on Kubuntu 17.10.

Originally created by @smitsohu on GitHub (Oct 9, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1599 KDE's ubiquitous KIO makes it quite easy to escape from a Firejail sandbox. Try the following: ``` kubuntu@kubuntu:~$ firejail --noprofile --seccomp --blacklist=/home/kubuntu/sample.pdf Parent pid 11228, child pid 11229 Child process initialized in 34.96 ms kubuntu@kubuntu:~$ kioclient exec /home/kubuntu/sample.pdf kbuildsycoca4 running... kubuntu@kubuntu:~$ ``` We blacklist a pdf file which we then successfully open with kioclient from inside the jail. In a second terminal we can see that `firejail --tree` doesn't list the pdf reader, it has escaped the sandbox. Also the seccomp filter is lost. ``` kubuntu@kubuntu:~$ firejail --tree 11020:kubuntu:firejail --noprofile --seccomp --blacklist=/home/kubuntu/sample.pdf 11021:kubuntu:firejail --noprofile --seccomp --blacklist=/home/kubuntu/sample.pdf 11023:kubuntu:/bin/bash 11179:kubuntu:firejail --tree kubuntu@kubuntu:~$ ps -C okular PID TTY TIME CMD 11087 ? 00:00:03 okular kubuntu@kubuntu:~$ grep Seccomp /proc/11087/status Seccomp: 0 kubuntu@kubuntu:~$ ``` Probably relevant to #1594 EDIT: looking a bit further, this is getting confusing. Not all applications escape, and behavior changes over time. For example Firefox escapes on Debian Jessie Mate, but not on Kubuntu 17.10.

gitea-mirror

2026-05-05 07:24:38 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 07:24:43 -06:00

Author

Owner

@netblue30 commented on GitHub (Oct 10, 2017):

What happens if you run "sudo firecfg"?. This should set the symbolic link in /usr/local/bin, so when okular is started it will firejailed automatically.

@netblue30 commented on GitHub (Oct 10, 2017): What happens if you run "sudo firecfg"?. This should set the symbolic link in /usr/local/bin, so when okular is started it will firejailed automatically.

gitea-mirror commented

2026-05-05 07:24:45 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 10, 2017):

Yes, okular starts inside a new sandbox when a symbolic link is set in /usr/local/bin. While "sudo firecfg" cannot really solve the issue, it certainly helps to some extent.

The first idea was to address this by dbus isolation, and it works in many cases. But there is reason to doubt it works reliably. A Thunderbird jail on KDE with net eth0 and apparmor, set to use xdg-open for handling pdf attachments, still allows Okular to escape the sandbox somehow.

@smitsohu commented on GitHub (Oct 10, 2017): Yes, okular starts inside a new sandbox when a symbolic link is set in /usr/local/bin. While "sudo firecfg" cannot really solve the issue, it certainly helps to some extent. The first idea was to address this by dbus isolation, and it works in many cases. But there is reason to doubt it works reliably. A Thunderbird jail on KDE with `net eth0` and `apparmor`, set to use xdg-open for handling pdf attachments, still allows Okular to escape the sandbox somehow.

gitea-mirror commented

2026-05-05 07:24:46 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 11, 2017):

The real problem is kdeinit itself, which lives outside the jail and waits for requests to launch new applications. Try with the kshell command, again Okular (or any other application) escapes from the sandbox:

kubuntu@kubuntu:~$ firejail --noprofile --net=none
Parent pid 10290, child pid 10291
Child process initialized in 44.93 ms
kubuntu@kubuntu:~$ kshell5 okular
Launched ok, pid = 10304
kubuntu@kubuntu:~$

This can be blocked by blacklisting the kdeinit sockets.

But there is another way to access kdeinit. From documentation, how KIO slaves get started:

your application requests 'klauncher' via DBus for a slave. If 'klauncher' does not have an idle slave ready, it will ask kdeinit to start a new one....

(it would be good to know what the communication channel between klauncher and kdeinit is)

Thus blacklisting kdeinit sockets is necessary, and isolating dbus is necessary equally. Both together are probably already sufficient.

@smitsohu commented on GitHub (Oct 11, 2017): The real problem is kdeinit itself, which lives outside the jail and waits for requests to launch new applications. Try with the kshell command, again Okular (or any other application) escapes from the sandbox: ``` kubuntu@kubuntu:~$ firejail --noprofile --net=none Parent pid 10290, child pid 10291 Child process initialized in 44.93 ms kubuntu@kubuntu:~$ kshell5 okular Launched ok, pid = 10304 kubuntu@kubuntu:~$ ``` This can be blocked by blacklisting the kdeinit sockets. But there is another way to access kdeinit. [From documentation, how KIO slaves get started](https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves#How_does_an_io-slave_get_started.3F): > your application requests 'klauncher' via DBus for a slave. If 'klauncher' does not have an idle slave ready, it will ask kdeinit to start a new one.... (it would be good to know what the communication channel between klauncher and kdeinit is) Thus blacklisting kdeinit sockets is necessary, and isolating dbus is necessary equally. Both together are probably already sufficient.

gitea-mirror commented

2026-05-05 07:24:47 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 15, 2017):

Issue was brought up already in #1256

@smitsohu commented on GitHub (Oct 15, 2017): Issue was brought up already in #1256

gitea-mirror commented

2026-05-05 07:24:49 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 18, 2017):

d9ba74da22 causes trouble when the kdeinit process gets killed, and it is tried to start it again inside firejail (binding to the blacklisted pathname fails).

This appears to be an issue mainly for kdeinit4... see #725 why it may look tempting to kill kdeinit4 (amarok is a more reliable test case than okular though).

Related note: If the kdeinit4 process runs inside a sandbox, which should be the case when all KDE apps are firejailed automatically and the desktop environment is not KDE4, sandbox escapes are also prevented. So "sudo firecfg" is indeed an alternative to blacklisting the kdeinit4 socket (except on the KDE4 desktop).

My suggestion would be then to blacklist only the kdeinit5 socket. Different opinions, better ideas?

@smitsohu commented on GitHub (Oct 18, 2017): d9ba74da220680ed019461a7b832ae1e61798b1f causes trouble when the kdeinit process gets killed, and it is tried to start it again inside firejail (binding to the blacklisted pathname fails). This appears to be an issue mainly for kdeinit4... see #725 why it may look tempting to kill kdeinit4 (amarok is a more reliable test case than okular though). Related note: If the kdeinit4 process runs inside a sandbox, which should be the case when all KDE apps are firejailed automatically and the desktop environment is not KDE4, sandbox escapes are also prevented. So "sudo firecfg" is indeed an alternative to blacklisting the kdeinit4 socket (except on the KDE4 desktop). My suggestion would be then to blacklist only the kdeinit5 socket. Different opinions, better ideas?

gitea-mirror commented

2026-05-05 07:24:50 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Oct 20, 2017):

@smitsohu : I tried to reproduce your example in the first post on Fedora 26.

With the symlink for okular in /usr/local/bin removed:

22851:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 
  22852:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 
    22854:hank:/bin/bash 
      23105:hank:/bin/bash 
        23790:hank:/bin/bash 
    23432:hank:kdeinit4: kdeinit4 Running...
      23434:hank:kdeinit4: klauncher [kdeinit] --fd=8
      13391:hank:/usr/bin/okular /home/hank/Example.pdf 
    23436:hank:kdeinit4: kded4 [kdeinit]   
    23438:hank:/usr/libexec/gam_server

With the symlink for okular in /usr/local/bin moved back I got this warning:

Warning: an existing sandbox was detected. /usr/bin/okular will run without any additional sandboxing features

... but:

22851:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 
  22852:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 
    22854:hank:/bin/bash 
      23105:hank:/bin/bash 
        23790:hank:/bin/bash 
    23432:hank:kdeinit4: kdeinit4 Running...
      23434:hank:kdeinit4: klauncher [kdeinit] --fd=8
      14668:hank:/usr/bin/okular /home/hank/Example.pdf 
    23436:hank:kdeinit4: kded4 [kdeinit]   
    23438:hank:/usr/libexec/gam_server

So in both cases there is no sandbox escape for okular. But as you wrote there seems to be no consistent behavior. It might differ from distro to distro. It's confusing.

EDIT: FWIW, in both cases grep Seccomp /proc/xxxx/status gives this result for okular:
Seccomp: 2

@curiosity-seeker commented on GitHub (Oct 20, 2017): @smitsohu : I tried to reproduce your example in the first post on Fedora 26. 1. With the symlink for okular in /usr/local/bin **removed**: ``` 22851:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 22852:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 22854:hank:/bin/bash 23105:hank:/bin/bash 23790:hank:/bin/bash 23432:hank:kdeinit4: kdeinit4 Running... 23434:hank:kdeinit4: klauncher [kdeinit] --fd=8 13391:hank:/usr/bin/okular /home/hank/Example.pdf 23436:hank:kdeinit4: kded4 [kdeinit] 23438:hank:/usr/libexec/gam_server ``` 2. With the symlink for okular in /usr/local/bin moved back I got this warning: `Warning: an existing sandbox was detected. /usr/bin/okular will run without any additional sandboxing features` ... but: ``` 22851:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 22852:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 22854:hank:/bin/bash 23105:hank:/bin/bash 23790:hank:/bin/bash 23432:hank:kdeinit4: kdeinit4 Running... 23434:hank:kdeinit4: klauncher [kdeinit] --fd=8 14668:hank:/usr/bin/okular /home/hank/Example.pdf 23436:hank:kdeinit4: kded4 [kdeinit] 23438:hank:/usr/libexec/gam_server ``` So in both cases there is **no** sandbox escape for okular. But as you wrote there seems to be no consistent behavior. It might differ from distro to distro. It's confusing. EDIT: FWIW, in both cases `grep Seccomp /proc/xxxx/status` gives this result for okular: `Seccomp: 2`

gitea-mirror commented

2026-05-05 07:24:52 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 20, 2017):

@curiosity-seeker The recipe in the first post is lacking an ingredient, because I didn't properly understand the issue first: it works only if kdeinit4 already runs outside firejail. That's why kdeinit4 is an issue primarily for the Plasma 4 desktop (and also when not all KDE apps are firejailed), and kdeinit5 is an issue primarily for the Plasma 5 desktop.

Try it instead with kioclient5 exec /home/hank/Example.pdf. It will ask kdeinit5 for the service, which is always running unconfined in the background on Fedora 26.

In order to deny access to dbus on Fedora, use blacklist /run/user/enteryouruserid/bus.

@smitsohu commented on GitHub (Oct 20, 2017): @curiosity-seeker The recipe in the first post is lacking an ingredient, because I didn't properly understand the issue first: it works only if kdeinit4 already runs outside firejail. That's why kdeinit4 is an issue primarily for the Plasma 4 desktop (and also when not all KDE apps are firejailed), and kdeinit5 is an issue primarily for the Plasma 5 desktop. Try it instead with `kioclient5 exec /home/hank/Example.pdf`. It will ask kdeinit5 for the service, which is always running unconfined in the background on Fedora 26. In order to deny access to dbus on Fedora, use `blacklist /run/user/enteryouruserid/bus`.

gitea-mirror commented

2026-05-05 07:24:53 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Oct 20, 2017):

@smitsohu : Ah, yes, this makes a difference! Without blacklisting /run/user/1000/bus and with the symlink for okular in /usr/local/bin it starts sandboxed:

583:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 
  584:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 
    586:hank:/bin/bash 
1069:hank:/usr/bin/firejail /usr/bin/okular /home/hank/Example.pdf 
  1070:hank:/usr/bin/firejail /usr/bin/okular /home/hank/Example.pdf 
    1074:hank:/usr/bin/okular /home/hank/Example.pdf

Note that now - contrary to above example with kdeinit4 - okular does no longer run as a sub-process but as its own firejailed process.

And without the symlink okular is now unsandboxed!

But with blacklisting /run/user/1000/bus and without the symlink okular is sandboxed:

13280:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf --blacklist=/run/user/1000/bus 
  13281:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf --blacklist=/run/user/1000/bus 
    13283:hank:/bin/bash 
    13791:hank:/usr/bin/okular /home/hank/Example.pdf

It's now running as a sub-process - but okular produces an error message: Could not open file:///home/hank/Example.pdf, and on the console I get:

kdeinit5: Shutting down running client.
kdeinit5: Communication error with launcher. Exiting!

Same as above but with the symlink yields exactly the same result. Only difference is a different error message on the console:

kdeinit5: Shutting down running client.
kdeinit5: Communication error with launcher. Exiting!
Warning: an existing sandbox was detected. /usr/bin/okular will run without any additional sandboxing features

Okay ... what does that tell us?

@curiosity-seeker commented on GitHub (Oct 20, 2017): @smitsohu : Ah, yes, this makes a difference! **Without** blacklisting `/run/user/1000/bus` and **with** the symlink for okular in /usr/local/bin it starts sandboxed: ``` 583:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 584:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf 586:hank:/bin/bash 1069:hank:/usr/bin/firejail /usr/bin/okular /home/hank/Example.pdf 1070:hank:/usr/bin/firejail /usr/bin/okular /home/hank/Example.pdf 1074:hank:/usr/bin/okular /home/hank/Example.pdf ``` Note that now - contrary to above example with kdeinit4 - okular does no longer run as a sub-process but as its own firejailed process. And **without** the symlink okular is now unsandboxed! But **with** blacklisting `/run/user/1000/bus` and **without** the symlink okular is sandboxed: ``` 13280:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf --blacklist=/run/user/1000/bus 13281:hank:firejail --noprofile --seccomp --blacklist=/home/hank/Example.pdf --blacklist=/run/user/1000/bus 13283:hank:/bin/bash 13791:hank:/usr/bin/okular /home/hank/Example.pdf ``` It's now running as a _sub-process_ - but okular produces an error message: `Could not open file:///home/hank/Example.pdf`, and on the console I get: ``` kdeinit5: Shutting down running client. kdeinit5: Communication error with launcher. Exiting! ``` Same as above but **with** the symlink yields exactly the same result. Only difference is a different error message on the console: ``` kdeinit5: Shutting down running client. kdeinit5: Communication error with launcher. Exiting! Warning: an existing sandbox was detected. /usr/bin/okular will run without any additional sandboxing features ``` Okay ... what does that tell us?

gitea-mirror commented

2026-05-05 07:24:54 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 21, 2017):

It shows that dbus facilitates sandbox escapes (but this is no big news). A best practice, independent of the desktop environment, is to deny dbus access wherever it is possible.

On KDE it has traditionally been difficult to do this, because there used to be no KIO without dbus (like in #947).
But good news is that the situation is improving, and the ability to keep KIO while blocking dbus has already arrived in the KDE flavors of some distros.

@smitsohu commented on GitHub (Oct 21, 2017): It shows that dbus facilitates sandbox escapes (but this is no big news). A best practice, independent of the desktop environment, is to deny dbus access wherever it is possible. On KDE it has traditionally been difficult to do this, because there used to be no KIO without dbus (like in #947). But good news is that the situation is improving, and the ability to keep KIO while blocking dbus has already arrived in the KDE flavors of some distros.

gitea-mirror commented

2026-05-05 07:24:55 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Oct 21, 2017):

It shows that dbus facilitates sandbox escapes (but this is no big news). A best practice, independent of the desktop environment, is to deny dbus access wherever it is possible.

In my understanding of above tests this sandbox escape only happens if /run/user/1000/bus is not blacklisted and there is no symlink for the helper application. Yes, that case qualifies as a sandbox escape. But as already mentioned in #1594, using xdg-open in order to execute the helper application is no sandbox escape, IMHO, as without a private-bin line in the profile anything in /usr/bin is allowed to execute including xdg-open.

@curiosity-seeker commented on GitHub (Oct 21, 2017): > It shows that dbus facilitates sandbox escapes (but this is no big news). A best practice, independent of the desktop environment, is to deny dbus access wherever it is possible. In my understanding of above tests this sandbox escape only happens if `/run/user/1000/bus` is not blacklisted **and** there is no symlink for the helper application. Yes, that case qualifies as a sandbox escape. But as already mentioned in #1594, using xdg-open in order to execute the helper application is no sandbox escape, IMHO, as without a private-bin line in the profile anything in /usr/bin is allowed to execute including xdg-open.

gitea-mirror commented

2026-05-05 07:24:56 -06:00

Author

Owner

@smitsohu commented on GitHub (Oct 28, 2017):

d9ba74d causes trouble when the kdeinit process gets killed, and it is tried to start it again inside firejail (binding to the blacklisted pathname fails).

This appears to be an issue mainly for kdeinit4... see #725 why it may look tempting to kill kdeinit4

My suggestion would be then to blacklist only the kdeinit5 socket. Different opinions, better ideas?

A solution with obviously better confinement is to keep the kdeinit4 socket on the blacklist and to noblacklist it for a selection of apps, essentially the KDE apps.
Doing it this way should keep us supporting legacy installations (like Ubuntu 14.04, Centos 7 and so on).

EDIT: Just started it and it looks ugly. I doubt we want it. We need another solution.

@smitsohu commented on GitHub (Oct 28, 2017): > d9ba74d causes trouble when the kdeinit process gets killed, and it is tried to start it again inside firejail (binding to the blacklisted pathname fails). > This appears to be an issue mainly for kdeinit4... see #725 why it may look tempting to kill kdeinit4 > My suggestion would be then to blacklist only the kdeinit5 socket. Different opinions, better ideas? A solution with obviously better confinement is to keep the kdeinit4 socket on the blacklist and to noblacklist it for a selection of apps, essentially the KDE apps. Doing it this way should keep us supporting legacy installations (like Ubuntu 14.04, Centos 7 and so on). EDIT: Just started it and it looks ugly. I doubt we want it. We need another solution.

Rows
Columns

[GH-ISSUE #1599] sandbox escapes with kdeinit #1067