github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #389] Add feature to control/restrict communications through DBus #280

New issue

Closed

opened 2026-05-05 05:30:59 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 05:30:59 -06:00

Owner

Originally created by @brunonova on GitHub (Mar 27, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/389

Currently, all programs can access all of the passwords stored in the GNOME Keyring in unlocked keyrings without any control.
This access is done through DBus, which Firejail doesn't restrict, I think.

Creating a new network namespace with --net=none seems to block DBus completely, but that can break some other features (like the global menus in Ubuntu).

So, if at all possible, some options to control and restrict communications through DBus, and thus block access to GNOME Keyring (and others) would be nice.
Do you think this would be possible?

In AppArmor, it seems that this rule does the job, though I don't know if it's enough:

deny dbus interface=org.freedesktop.Secret.*,

However, AppArmor doesn't seem to work correctly inside mount namespaces, so I can't use this with Firejail.

Originally created by @brunonova on GitHub (Mar 27, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/389 Currently, all programs can access all of the passwords stored in the GNOME Keyring in unlocked keyrings without any control. This access is done through DBus, which Firejail doesn't restrict, I think. Creating a new network namespace with `--net=none` seems to block DBus completely, but that can break some other features (like the global menus in Ubuntu). So, if at all possible, some options to control and restrict communications through DBus, and thus block access to GNOME Keyring (and others) would be nice. Do you think this would be possible? --- In AppArmor, it seems that this rule does the job, though I don't know if it's enough: ``` deny dbus interface=org.freedesktop.Secret.*, ``` However, AppArmor doesn't seem to work correctly inside mount namespaces, so I can't use this with Firejail.

gitea-mirror

2026-05-05 05:30:59 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 05:31:04 -06:00

Author

Owner

@netblue30 commented on GitHub (Mar 28, 2016):

The only way to disable DBus in Firejail is to create a new network namespace: --net=none or --net=eth0, depending if you need network connectivity or not.

AppArmor seems to have support for filtering messages over DBus, probably a simple AppArmor filter will do the job.

In my opinion the real fix is not to use the keyring. The concept is broken, no amount of sandboxing will ever fix it. I would never put a password of any value in a keyring - anybody can read it from there.

@netblue30 commented on GitHub (Mar 28, 2016): The only way to disable DBus in Firejail is to create a new network namespace: --net=none or --net=eth0, depending if you need network connectivity or not. AppArmor seems to have support for filtering messages over DBus, probably a simple AppArmor filter will do the job. In my opinion the real fix is not to use the keyring. The concept is broken, no amount of sandboxing will ever fix it. I would never put a password of any value in a keyring - anybody can read it from there.

gitea-mirror commented

2026-05-05 05:31:05 -06:00

Author

Owner

@brunonova commented on GitHub (Mar 28, 2016):

AppArmor can indeed do this, as I mentioned, but it doesn't seem to work very well with mount namespaces.

With the current state of the keyring, I also don't store anything valuable there.
Maybe in the future (snappy/xdg-app?) they'll improve the security by allowing programs to access only the passwords they create, and require the user to enter his/her password before revealing them.

If you don't think it's possible or feasible to implement this feature, you may close this Issue.

@brunonova commented on GitHub (Mar 28, 2016): AppArmor can indeed do this, as I mentioned, but it doesn't seem to work very well with mount namespaces. With the current state of the keyring, I also don't store anything valuable there. Maybe in the future (snappy/xdg-app?) they'll improve the security by allowing programs to access only the passwords they create, and require the user to enter his/her password before revealing them. If you don't think it's possible or feasible to implement this feature, you may close this Issue.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#280

No description provided.

Rows
Columns