[GH-ISSUE #950] Add KDE's konsole to blacklisted terminal emulators

gitea-mirror commented

2026-05-05 06:20:43 -06:00

Owner

Originally created by @RalfJung on GitHub (Dec 1, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/950

disable-common contains a bunch of blacklisted terminal emulators, but KDE's konsole seems to be missing. When I run firejail konsole, I get full access to all files because KDE applications are started via D-Bus and hence run outside of the jail. Clearly this is a more general problem that can only be properly solved by firewalling D-Bus, but for now, adding konsole to the terminal emulator blacklist in disable-common would at least block the trivial exploit.

I added the following line locally:

blacklist ${PATH}/konsole

Originally created by @RalfJung on GitHub (Dec 1, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/950 `disable-common` contains a bunch of blacklisted terminal emulators, but KDE's `konsole` seems to be missing. When I run `firejail konsole`, I get full access to all files because KDE applications are started via D-Bus and hence run outside of the jail. Clearly this is a more general problem that can only be properly solved by firewalling D-Bus, but for now, adding konsole to the terminal emulator blacklist in `disable-common` would at least block the trivial exploit. I added the following line locally: ``` blacklist ${PATH}/konsole ```

gitea-mirror closed this issue

2026-05-05 06:20:47 -06:00

gitea-mirror commented

2026-05-05 06:20:52 -06:00

Author

Owner

@valoq commented on GitHub (Dec 1, 2016):

When I start kde application in Kubuntu 16.10 via konsole they are jailed as expected.
Please provide more info on how to reproduce the issue.

Applications that are started by dbus or systemd (gnome) are an issue. I think we need to do something in that regard as well. However I don't know much about dbus yet other then that it provides no security measures for isolation.

@valoq commented on GitHub (Dec 1, 2016): When I start kde application in Kubuntu 16.10 via konsole they are jailed as expected. Please provide more info on how to reproduce the issue. Applications that are started by dbus or systemd (gnome) are an issue. I think we need to do something in that regard as well. However I don't know much about dbus yet other then that it provides no security measures for isolation.

gitea-mirror commented

2026-05-05 06:20:54 -06:00

Author

Owner

@RalfJung commented on GitHub (Dec 1, 2016):

I am running in a KDE session in Debian testing. When I do firejail konsole, and then I do ls ~/*, I can see all folders. I thought they should all be hidden because all of them except for my downloads folder are hidden inside a firejail firefox. But indeed this is not specific to konsole, firejail bash can also see all these folders. I guess the actual problem is that I did not yet understand why for some profiles, all folders in my home directory are hidden by default, whereas for others, they are shown by default.

Other KDE applications however do break the jail, e.g. firejail dolphin can access files in ~/.ssh.

@RalfJung commented on GitHub (Dec 1, 2016): I am running in a KDE session in Debian testing. When I do `firejail konsole`, and then I do `ls ~/*`, I can see all folders. I thought they should all be hidden because all of them except for my downloads folder are hidden inside a `firejail firefox`. But indeed this is not specific to konsole, `firejail bash` can also see all these folders. I guess the actual problem is that I did not yet understand why for some profiles, all folders in my home directory are hidden by default, whereas for others, they are shown by default. Other KDE applications however *do* break the jail, e.g. `firejail dolphin` can access files in `~/.ssh`.

gitea-mirror commented

2026-05-05 06:20:57 -06:00

Author

Owner

@valoq commented on GitHub (Dec 1, 2016):

Other KDE applications however do break the jail, e.g. firejail dolphin can access files in ~/.ssh.

That should definitely not happen.
I can reproduce the issue and I assume other kde applications are affected as well.

The issue with dolphin is that it triggers certain sub-processes like file.so which are started by kdeinit5 outside of the jail.

A similar issue exists here #934 with gnome applications.

@netblue30
It seems firejail needs a way to handle request via dbus and systemd to be effective with gnome and kde applications as well as possibly others.
At the moment the only way is to isolate IPC completely which breaks many applications.
It would probably be best to force certain service applications like kdeinit5 to be automatically started separately inside the sandbox and block request to outside processes.

@valoq commented on GitHub (Dec 1, 2016): > Other KDE applications however do break the jail, e.g. firejail dolphin can access files in ~/.ssh. That should definitely not happen. I can reproduce the issue and I assume other kde applications are affected as well. The issue with dolphin is that it triggers certain sub-processes like file.so which are started by kdeinit5 outside of the jail. A similar issue exists here #934 with gnome applications. @netblue30 It seems firejail needs a way to handle request via dbus and systemd to be effective with gnome and kde applications as well as possibly others. At the moment the only way is to isolate IPC completely which breaks many applications. It would probably be best to force certain service applications like kdeinit5 to be automatically started separately inside the sandbox and block request to outside processes.

gitea-mirror commented

2026-05-05 06:21:02 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Dec 1, 2016):

I am running in a KDE session in Debian testing. When I do firejail konsole, and then I do ls ~/*, I can see all folders. I thought they should all be hidden because all of them except for my downloads folder are hidden inside a firejail firefox. But indeed this is not specific to konsole, firejail bash can also see all these folders.

This is not surprising. In Firefox you can only see the folders which are explicitly whitelisted. However, there are no profiles for konsole and bash. Hence, if you execute them with Firejail the default.profile is applied which only blacklists the stuff contained in the included *.inc files.

@curiosity-seeker commented on GitHub (Dec 1, 2016): > I am running in a KDE session in Debian testing. When I do firejail konsole, and then I do ls ~/*, I can see all folders. I thought they should all be hidden because all of them except for my downloads folder are hidden inside a firejail firefox. But indeed this is not specific to konsole, firejail bash can also see all these folders. This is not surprising. In Firefox you can only see the folders which are explicitly whitelisted. However, there are no profiles for konsole and bash. Hence, if you execute them with Firejail the `default.profile` is applied which only blacklists the stuff contained in the included *.inc files.

gitea-mirror commented

2026-05-05 06:21:05 -06:00

Author

Owner

@RalfJung commented on GitHub (Dec 1, 2016):

This is not surprising. In Firefox you can only see the folders which are explicitly whitelisted.

That doesn't seem to be entirely correct; for example, I can see /mnt/store in Firefox which is where I mount by HDD (with $HOME being on an SSD).
So far, I have not figured out when exactly firejail switches to "whitelist mode"...

@RalfJung commented on GitHub (Dec 1, 2016): > This is not surprising. In Firefox you can only see the folders which are explicitly whitelisted. That doesn't seem to be entirely correct; for example, I *can* see `/mnt/store` in Firefox which is where I mount by HDD (with `$HOME` being on an SSD). So far, I have not figured out when exactly firejail switches to "whitelist mode"...

gitea-mirror commented

2026-05-05 06:21:07 -06:00

Author

Owner

@curiosity-seeker commented on GitHub (Dec 1, 2016):

It switches to whitelist mode if that command is used in the respective profile. I was talking about your home directory.

If you input

file:///home/<username>

in the Firefox address line you'll see which folders are accessible in your home - those are the files/folders whitelisted in firefox.profile. But /mnt is outside of home so the whitelist rules do not apply. On the other hand, in the included *.inc files there are no blacklist commands regarding mnt. If you want to blacklist it you have to add an appropriate rule yourself.

@curiosity-seeker commented on GitHub (Dec 1, 2016): It switches to whitelist mode if that command is used in the respective profile. I was talking about your home directory. If you input `file:///home/<username>` in the Firefox address line you'll see which folders are accessible in your home - those are the files/folders whitelisted in firefox.profile. But /mnt is outside of home so the whitelist rules do not apply. On the other hand, in the included *.inc files there are no blacklist commands regarding mnt. If you want to blacklist it you have to add an appropriate rule yourself.

gitea-mirror commented

2026-05-05 06:21:09 -06:00

Author

Owner

@RalfJung commented on GitHub (Dec 1, 2016):

It switches to whitelist mode if that command is used in the respective profile. I was talking about your home directory.

Ah, I finally found the explanation:

              Whitelist directory or file. A temporary file system is mounted on the top directory, and the whitelisted files are mount-binded inside. Modifications to whitelisted files are persistent, everything else is  discarded
              when the sandbox is closed. The top directory could be user home, /dev, /media, /mnt, /opt, /srv, /var, and /tmp.

So doing whitelist for anything in /home enables whitelist mode for /home only. Understood.
Lucky enough, /mnt is in that list too, so I can also enabled whitelist mode for it. If I was using another (non-standard) top directory I guess I would have been out of luck?

Anyway, this bug can be closed. Thanks for your quick replies!

@RalfJung commented on GitHub (Dec 1, 2016): > It switches to whitelist mode if that command is used in the respective profile. I was talking about your home directory. Ah, I finally found the explanation: ``` Whitelist directory or file. A temporary file system is mounted on the top directory, and the whitelisted files are mount-binded inside. Modifications to whitelisted files are persistent, everything else is discarded when the sandbox is closed. The top directory could be user home, /dev, /media, /mnt, /opt, /srv, /var, and /tmp. ``` So doing `whitelist` for anything in `/home` enables whitelist mode *for `/home` only*. Understood. Lucky enough, `/mnt` is in that list too, so I can also enabled whitelist mode for it. If I was using another (non-standard) top directory I guess I would have been out of luck? Anyway, this bug can be closed. Thanks for your quick replies!

gitea-mirror referenced this issue

2026-05-05 10:06:16 -06:00

[PR #646] [MERGED] Fix spelling errors found by lintian #3697

gitea-mirror referenced this issue

2026-05-05 10:37:18 -06:00

[PR #5140] [MERGED] build: deduplicate configure-time vars into new config files #5376

Rows
Columns

[GH-ISSUE #950] Add KDE's konsole to blacklisted terminal emulators #646