[GH-ISSUE #1822] Recalibration of D-Bus access

gitea-mirror commented

2026-05-05 07:42:33 -06:00

Owner

Originally created by @smitsohu on GitHub (Mar 18, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1822

We have three different options that govern whether an app is allowed access to D-Bus or not....

apparmor: reliably shuts down all D-Bus access in Ubuntu and its derivatives
net none: denies access to the session bus in Ubuntu 16.04 (Mint!), Debian Jessie.... in general distributions that were released some time ago. Also kills connection to the accessibility bus.
blacklist /run/user/*/bus: denies access to the session bus in newer distribution releases.

Now that we are adding apparmor to many profiles (184ecb305e, 38ffc3f025, 971c62aa56, d8b4a63320), I thought it might be a good timepoint to take a step back and reconsider how we want to address the D-Bus issue.

In a number profiles right now only one or two or these three options are enabled, which seems to be, at first glance at least, an inconsistent state. The rigorous approach would be to go through these profiles and either enable them all or comment them all (net none obviously can't go to some profiles).... that's IMHO the only way to ensure a smooth and consistent user experience everywhere.

But then, as many Ubuntu (and Mint) users are expected to switch to upcoming Ubuntu 18.04 LTS, the number of people who may run into problems with net none should decrease considerably. Also the KDE file chooser works without D-Bus since recently. And finally, given how big a security hole D-Bus is, the ability to change application settings could also be considered minor in comparison (thinking of apps like eog or gedit).

Personally I have a lot of sympathies for a stricter approach to D-Bus. The question is if we are willing to move ahead even if it will cause problems for users with older software. Also I think we should try to combine apparmor with blacklist /run/user/*/bus (and net none where possible) to ensure consistently working profiles.

Originally created by @smitsohu on GitHub (Mar 18, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1822 We have three different options that govern whether an app is allowed access to D-Bus or not.... - `apparmor`: reliably shuts down all D-Bus access in Ubuntu and its derivatives - `net none`: denies access to the session bus in Ubuntu 16.04 (Mint!), Debian Jessie.... in general distributions that were released some time ago. Also kills connection to the accessibility bus. - `blacklist /run/user/*/bus`: denies access to the session bus in newer distribution releases. Now that we are adding `apparmor` to many profiles (184ecb305e81942fa9218f14a93f584fbeaff230, 38ffc3f02575ee91fe0dbf92e6b8ebc93095e667, 971c62aa569d9161190705a0012b9ad02546822c, d8b4a633202a13a13c75779d1f40a99d6cc51dfb), I thought it might be a good timepoint to take a step back and reconsider how we want to address the D-Bus issue. In a number profiles right now only one or two or these three options are enabled, which seems to be, at first glance at least, an inconsistent state. The rigorous approach would be to go through these profiles and either enable them all or comment them all (`net none` obviously can't go to some profiles).... that's IMHO the only way to ensure a smooth and consistent user experience _everywhere_. But then, as many Ubuntu (and Mint) users are expected to switch to upcoming Ubuntu 18.04 LTS, the number of people who may run into problems with `net none` should decrease considerably. Also the KDE file chooser works without D-Bus since recently. And finally, given how big a security hole D-Bus is, the ability to change application settings could also be considered minor in comparison (thinking of apps like eog or gedit). Personally I have a lot of sympathies for a stricter approach to D-Bus. The question is if we are willing to move ahead even if it will cause problems for users with older software. Also I think we should try to combine `apparmor` with `blacklist /run/user/*/bus` (and `net none` where possible) to ensure consistently working profiles.

gitea-mirror

2026-05-05 07:42:33 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Mar 18, 2018):

Some thoughts:
net none affecting dbus is coincidental. It can't be used when application need network access.
apparmor isn't available in all distributions so we can't rely on it alone.

@Vincent43 commented on GitHub (Mar 18, 2018): Some thoughts: `net none` affecting dbus is coincidental. It can't be used when application need network access. `apparmor` isn't available in all distributions so we can't rely on it alone.

gitea-mirror commented

2026-05-05 07:42:40 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 18, 2018):

@Vincent43

net none affecting dbus is coincidental. It can't be used when application need network access.

That's right, I've updated my original post to make my point clearer.

@smitsohu commented on GitHub (Mar 18, 2018): @Vincent43 > net none affecting dbus is coincidental. It can't be used when application need network access. That's right, I've updated my original post to make my point clearer.

gitea-mirror commented

2026-05-05 07:42:42 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Mar 20, 2018):

@smitsohu and @Vincent43 Do you know why net none doesn't stop dbus access on newer distros?

@Fred-Barclay commented on GitHub (Mar 20, 2018): @smitsohu and @Vincent43 Do you know why net none doesn't stop dbus access on newer distros?

gitea-mirror commented

2026-05-05 07:42:44 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 20, 2018):

Replying to myself @smitsohu

The question is if we are willing to move ahead even if it will cause problems for users with older software.

Turns out this is a cipher for Kubuntu 16.04.... problems with apparmor are basically limited to this release (file chooser in KDE apps, Chromium, VLC).

Also I think we should try to combine apparmor with blacklist /run/user/*/bus (and net none where possible) to ensure consistently working profiles.

A compromise could be that we keep apparmor as it is now and not enable blacklist /run/user/*/bus and net none in KDE apps or Chromium or VLC profiles, so that this problem effectively is contained to Kubuntu 16.04.

(actually blacklist /run/user/*/bus would be a possible addition to chromium-common.profile, with env NO_CHROME_KDE_FILE_DIALOG=1 as a workaround)

Which still leaves us with:

And finally, given how big a security hole D-Bus is, the ability to change application settings could also be considered minor in comparison (thinking of apps like eog or gedit).

If not being able to change settings is considered an acceptable price for D-Bus isolation, we should uncomment blacklist /run/user/*/bus and net none in a number of profiles, in addition to apparmor. Indeed we seem to have entered a similar trade-off already with whitelisting, see #1793.

@smitsohu commented on GitHub (Mar 20, 2018): Replying to myself @smitsohu > The question is if we are willing to move ahead even if it will cause problems for users with older software. Turns out this is a cipher for Kubuntu 16.04.... problems with `apparmor` are basically limited to this release (file chooser in KDE apps, Chromium, VLC). > Also I think we should try to combine apparmor with blacklist /run/user/*/bus (and net none where possible) to ensure consistently working profiles. A compromise could be that we keep `apparmor` as it is now and **not** enable `blacklist /run/user/*/bus` and `net none` in KDE apps or Chromium or VLC profiles, so that this problem effectively is contained to Kubuntu 16.04. (actually `blacklist /run/user/*/bus` would be a possible addition to chromium-common.profile, with `env NO_CHROME_KDE_FILE_DIALOG=1` as a workaround) Which still leaves us with: > And finally, given how big a security hole D-Bus is, the ability to change application settings could also be considered minor in comparison (thinking of apps like eog or gedit). If not being able to change settings is considered an acceptable price for D-Bus isolation, we should uncomment `blacklist /run/user/*/bus` and `net none` in a number of profiles, in addition to `apparmor`. Indeed we seem to have entered a similar trade-off already with whitelisting, see #1793.

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Mar 20, 2018):

Maybe it is easier to discuss with a pull request, I will try to compile something.

@Fred-Barclay D-Bus daemon and applications use a socket for communication, and the default location of this socket changed at some point.

Previously it was an abstract socket, which means it did not exist in the filesystem but only as a network resource. Nowadays the socket is bound to a file path (i.e. /run/user/$UID/bus), it does not exist as a network resource anymore (so that net is without effect).

I just found this discussion that apparently started it all: https://lists.freedesktop.org/archives/dbus/2014-December/016473.html

@smitsohu commented on GitHub (Mar 20, 2018): Maybe it is easier to discuss with a pull request, I will try to compile something. @Fred-Barclay D-Bus daemon and applications use a socket for communication, and the default location of this socket changed at some point. Previously it was an abstract socket, which means it did not exist in the filesystem but only as a network resource. Nowadays the socket is bound to a file path (i.e. /run/user/$UID/bus), it does not exist as a network resource anymore (so that `net` is without effect). I just found this discussion that apparently started it all: https://lists.freedesktop.org/archives/dbus/2014-December/016473.html

gitea-mirror commented

2026-05-05 07:42:48 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Mar 20, 2018):

@smitsohu Thanks!
I'm doing some testing with virtual machines and it looks like apparmor doesn't stop dbus access on at least Mint 18.3 and earlier (Ubuntu 16.04 base) since apparmor isn't provided by default.
If so then we probably can't count on apparmor stopping dbus for these distros since a majority of users may not have installed apparmor on their systems.

@Fred-Barclay commented on GitHub (Mar 20, 2018): @smitsohu Thanks! I'm doing some testing with virtual machines and it looks like `apparmor` doesn't stop dbus access on at least Mint 18.3 and earlier (Ubuntu 16.04 base) since apparmor isn't provided by default. If so then we probably can't count on `apparmor` stopping dbus for these distros since a majority of users may not have installed apparmor on their systems.

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Mar 20, 2018):

@Fred-Barclay

I'm doing some testing with virtual machines and it looks like apparmor doesn't stop dbus access, at least on Mint 18.3 and earlier (Ubuntu 14.04 base) since apparmor isn't provided by default.

Then it is really only Kubuntu 16.04, other Ubuntu 16.04 flavors don't have these big problems.

I didn't yet travel back in time so far 😄

@smitsohu commented on GitHub (Mar 20, 2018): @Fred-Barclay > I'm doing some testing with virtual machines and it looks like apparmor doesn't stop dbus access, at least on Mint 18.3 and earlier (Ubuntu 14.04 base) since apparmor isn't provided by default. Then it is really only Kubuntu 16.04, other Ubuntu 16.04 flavors don't have these big problems. I didn't yet travel back in time so far :smile:

gitea-mirror commented

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

Author

Owner

@Fred-Barclay commented on GitHub (Mar 20, 2018):

😄 I did have a typo in that quote - Mint 18.3 is actually a Ubuntu 16.04 derivative. Oops!

@Fred-Barclay commented on GitHub (Mar 20, 2018): :smile: I did have a typo in that quote - Mint 18.3 is actually a Ubuntu **16.04** derivative. Oops!

gitea-mirror commented

2026-05-05 07:42:51 -06:00

Author

Owner

@Vincent43 commented on GitHub (Mar 20, 2018):

Mint disables apparmor on Ubuntu kernels? Weird.

@Vincent43 commented on GitHub (Mar 20, 2018): Mint disables apparmor on Ubuntu kernels? Weird.

gitea-mirror commented

2026-05-05 07:42:51 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Mar 20, 2018):

@Vincent43 Clearly I need to do a bit more investigation! Apparmor is present on Mint 18.3:

user1@Mint183-VM ~ $ dpkg -l | grep apparmor
ii  apparmor                                    2.10.95-0ubuntu2.9                           amd64        user-space parser utility for AppArmor
ii  libapparmor-perl                            2.10.95-0ubuntu2.9                           amd64        AppArmor library Perl bindings
ii  libapparmor1:amd64                          2.10.95-0ubuntu2.9                           amd64        changehat AppArmor library

However,

user1@Mint183-VM ~ $ firejail --apparmor
Error: invalid --apparmor command line option

and when compiling with ./configure --prefix=/usr --enable-apparmor, the necesary headers and etc aren't present by default,

checking for unistd.h... yes
checking sys/apparmor.h usability... no
checking sys/apparmor.h presence... no
checking for sys/apparmor.h... no
configure: error: Couldn't find sys/apparmor.h... please install apparmor user space library and development files

This is for firejail built from git. I don't know if the firejail in the repos (0.9.38) or 0.9.52 provided on sourceforge have apparmor enabled; probably @reinerh would know.

UPDATE: firejail 0.9.50 in artful's (Ubuntu 17.10) repos does come with apparmor support. Same as above, though, the headers aren't present on the system so we can't necessarily assume that just because someone is using Ubuntu or Mint that apparmor is enabled for them. If they built from git there's a good chance it isn't.

@Fred-Barclay commented on GitHub (Mar 20, 2018): @Vincent43 Clearly I need to do a bit more investigation! Apparmor is present on Mint 18.3: ``` user1@Mint183-VM ~ $ dpkg -l | grep apparmor ii apparmor 2.10.95-0ubuntu2.9 amd64 user-space parser utility for AppArmor ii libapparmor-perl 2.10.95-0ubuntu2.9 amd64 AppArmor library Perl bindings ii libapparmor1:amd64 2.10.95-0ubuntu2.9 amd64 changehat AppArmor library ``` However, ``` user1@Mint183-VM ~ $ firejail --apparmor Error: invalid --apparmor command line option ``` and when compiling with `./configure --prefix=/usr --enable-apparmor`, the necesary headers and etc aren't present by default, ``` checking for unistd.h... yes checking sys/apparmor.h usability... no checking sys/apparmor.h presence... no checking for sys/apparmor.h... no configure: error: Couldn't find sys/apparmor.h... please install apparmor user space library and development files ``` This is for firejail built from git. I don't know if the firejail in the repos (0.9.38) or 0.9.52 provided on sourceforge have apparmor enabled; probably @reinerh would know. UPDATE: firejail 0.9.50 in artful's (Ubuntu 17.10) repos **does** come with apparmor support. Same as above, though, the headers aren't present on the system so we can't necessarily assume that just because someone is using Ubuntu or Mint that apparmor is enabled for them. If they built from git there's a good chance it isn't.

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Mar 20, 2018):

I guess you need this for building against apparmor https://packages.ubuntu.com/xenial/libapparmor-dev

There should be a lot more apparmor packages: https://packages.ubuntu.com/search?keywords=apparmor&searchon=names&suite=xenial&section=all

@Vincent43 commented on GitHub (Mar 20, 2018): I guess you need this for building against apparmor https://packages.ubuntu.com/xenial/libapparmor-dev There should be a lot more apparmor packages: https://packages.ubuntu.com/search?keywords=apparmor&searchon=names&suite=xenial&section=all

gitea-mirror commented

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

Author

Owner

@Fred-Barclay commented on GitHub (Mar 20, 2018):

@Vincent43 dpkg -l shows installed packages only. It doesn't search the repos. 😉

@Fred-Barclay commented on GitHub (Mar 20, 2018): @Vincent43 `dpkg -l` shows installed packages only. It doesn't search the repos. :wink:

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Mar 21, 2018):

Guys, just disregard apparmor for now! It is there in case Canonical decides to upstream their apparmor modifications and bring in proper support to control D-Bus into the kernel. They were supposed to do it two years ago.

@smitsohu:

A compromise could be that we keep apparmor as it is now and not enable blacklist /run/user/*/bus and net none in KDE apps or Chromium or VLC profiles, so that this problem effectively is contained to Kubuntu 16.04.

Let's go with this proposal. If apparmor breaks, we ask the user to disable it until we find a fix. Disabling apparmor in firejail is very easy - just disable the apparmor profile in the kernel:

$ sudo aa-disable /etc/apparmor.d/firejail-default

The difficult part is to enable it. You would need to build firejail with apparmor support:

$ ./configure --prefix=/usr --enable-apparmor

There is a package you need to install (libapparmor-dev on Debian, apparmor-libapparmor on Arch). The full instructions are here: https://wiki.debian.org/AppArmor/HowToUse (Debian), https://wiki.archlinux.org/index.php/AppArmor (Arch)

@netblue30 commented on GitHub (Mar 21, 2018): Guys, just disregard apparmor for now! It is there in case Canonical decides to upstream their apparmor modifications and bring in proper support to control D-Bus into the kernel. They were supposed to do it two years ago. @smitsohu: > A compromise could be that we keep apparmor as it is now and not enable blacklist /run/user/*/bus and net none in KDE apps or Chromium or VLC profiles, so that this problem effectively is contained to Kubuntu 16.04. Let's go with this proposal. If apparmor breaks, we ask the user to disable it until we find a fix. Disabling apparmor in firejail is very easy - just disable the apparmor profile in the kernel: ````` $ sudo aa-disable /etc/apparmor.d/firejail-default ````` The difficult part is to enable it. You would need to build firejail with apparmor support: ````` $ ./configure --prefix=/usr --enable-apparmor ````` There is a package you need to install (libapparmor-dev on Debian, apparmor-libapparmor on Arch). The full instructions are here: https://wiki.debian.org/AppArmor/HowToUse (Debian), https://wiki.archlinux.org/index.php/AppArmor (Arch)

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Mar 21, 2018):

@netblue30 they want to upstream it. Dbus control was supposed to land in linux 4.15 but it was blocked by Linus himself (it would break all existing profiles outside ubuntu/suse which don't handle dbus access). As a workaround they had to bring policy versioning to userspace first (which is ready and was deployed to debian). Linux 4.17 is current target to upstream more things from apparmor.

@Vincent43 commented on GitHub (Mar 21, 2018): @netblue30 they want to upstream it. Dbus control was supposed to land in linux 4.15 but it was blocked by Linus himself (it would break all existing profiles outside ubuntu/suse which don't handle dbus access). As a workaround they had to bring policy versioning to userspace first (which is ready and was deployed to debian). Linux 4.17 is current target to upstream more things from apparmor.

gitea-mirror commented

2026-05-05 07:42:57 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 29, 2018):

Sorry for this commit mess here!

@smitsohu commented on GitHub (Mar 29, 2018): Sorry for this commit mess here!

gitea-mirror referenced this issue

2026-05-05 10:09:53 -06:00

[PR #1239] [MERGED] noexec ~/.local/share #3894

gitea-mirror referenced this issue

2026-05-05 10:09:54 -06:00