-
Notifications
You must be signed in to change notification settings - Fork 569
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
profiles: add dbus filters #3326
profiles: add dbus filters #3326
Conversation
BTW: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First of all, thanks for creating the DBus profiles!
In the previous weeks, I was running the DBus filter with much tighter rules. As I use sway
, not Gnome, desktop integration wasn't a problem, so I may be overly vigilant. Nevertheless, below I made some comments regarding the filter rules from flathub.
etc/celluloid.profile
Outdated
dbus-user.talk org.gtk.vfs.* | ||
dbus-user.talk org.gtk.vfs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is allowing Gvfs access safe? Could for example a malicious application access any Gvfs mount (and potentially e.g., spread ransomware to an unsecured samba mount, using the credentials already provided to Gvfs by the user)?
Also, I don't think you need org.gtk.vfs
here, org.gtk.vfs.*
covers it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved other org.gtk.vfs
commend in order to have one thread.
Your right, the most programs don't need it.
TODO: can it be used to bypass disable-mnt
/blacklist
/whitelist
.
# - In order to make dconf work (if it is used by the app) you need to allow | ||
# 'ca.desrt.dconf' even if it is not allowed by flatpak. | ||
#dbus-user filter | ||
#dbus-user.own com.github.netblue30.firejail |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allowing any firejailed application to own the name com.github.netblue30.firejail
(and potentially impersonate firejail, if we ever add any custom DBus interfaces) sounds a bit risky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thats just an example, it would not pass any review. However we can change it to com.example.appname
.
# 'ca.desrt.dconf' even if it is not allowed by flatpak. | ||
#dbus-user filter | ||
#dbus-user.own com.github.netblue30.firejail | ||
#dbus-user.talk ca.desrt.dconf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure whether unrestricted DConf access is always a good idea. A malicious application could, for example, change stuff under org.gnome.system.proxy
to MITM traffic.
Luckily, users could just ignore dbus-user.talk ca.desrt.dconf
in globals.local
, and selectively enable it for applications that absolutely need it.
I wonder what's the flatpak solution for this vulnerability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder what's the flatpak solution for this vulnerability.
https://docs.flatpak.org/en/latest/sandbox-permissions.html#dconf-access, a lot of flatpaks still use direct access. gnome-builder suggests it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A malicious application could, for example, change stuff under
org.gnome.system.proxy
to MITM traffic.
Or even worser: /org/gnome/terminal/legacy/profiles:/<UUID>/custom-command
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only added it there as an example since it is common used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A sandboxed dconf similar to flatpak's would be a logical next step after DBus
etc/feedreader.profile
Outdated
dbus-user.own org.gnome.FeedReader.ArticleView | ||
dbus-user.talk org.freedesktop.Notifications | ||
dbus-user.talk org.gtk.vfs.* | ||
dbus-user.talk org.freedesktop.secrets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the access policy of the secret service? I think at least Gnome keyring only asks for the user password once (at most, never if PAM unlocks it), and provides secrets to application without any confirmation required. Although arguably, that's a vulnerability in the secret service implementation (I'm pretty sure keepassxc can be set to ask for confirmation before releasing credentials), not in the sandbox.
Well, that socket is the proxy socket, so it should be present. But yeah, I should fix the audit so it does not emit a warning, it makes no sense to warn for a properly running filter. |
etc/firefox.profile
Outdated
@@ -28,5 +28,11 @@ include whitelist-usr-share-common.inc | |||
# private-etc must first be enabled in firefox-common.profile | |||
#private-etc firefox | |||
|
|||
dbus-user filter | |||
dbus-user.own org.mozilla.firefox.* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Starting with Firefox 75, there should probably also be a dbus-user.own org.mpris.MediaPlayer2.firefox.*
for hardware media key support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to start minimal, there a lot more path for firefox + extensions. The policy used by the inoffical firefox-flatpak:
dbus-user filter
dbus-user.own org.mozilla.Firefox
dbus-user.own org.mozilla.firefox.*
dbus-user.talk org.freedesktop.FileManager1
dbus-user.talk org.freedesktop.Notifications
dbus-user.talk org.freedesktop.ScreenSaver
dbus-user.talk org.gnome.SessionManager
dbus-system filter
dbus-system.talk org.freedesktop.NetworkManager
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoah, org.freedesktop.NetworkManager
sounds quite evil in this context (MITM via adding a VPN, or leaking IP and MAC addresses of interfaces otherwise isolated with --net=
).
@rusty-snake I was going to replace all
as a general starting point Ok to push here or should I open a new PR? It's probably lots of files so didn't want to clutter up this PR. |
@Fred-Barclay if you push upstream, I can rebase. Nitpick: I used |
@rusty-snake I'm usually bad at alphabetising... in this case though for consistency's sake I'd guess |
The must profiles will disable dbus or look like the example below. For my eyes it was nicer to have a
The addresses (grouped by own and talk) should be alphabetical sure. |
See - 07fac58 for new dbus filters - #3326 (comment) Except for ocenaudio, access/restrictions on dbus options should be unchanged Ocenaudio profile: dbus filters were sandboxed (initially `nodbus` was enabled) since comments indicated blocking dbus meant preferences were broken
@rusty-snake done, see 3848b98 There are a few small changes left, like how to handle |
etc/firefox.profile
Outdated
dbus-user.own org.mozilla.firefox.* | ||
dbus-user.talk org.freedesktop.Notifications | ||
dbus-system none | ||
ignore nodbus |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I get why we need to have ignore nodbus
here. Does that mean we can remove it from firefox-common-addons.inc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now needs to be ignore dbus-user none
.
firefox-common.profile is used by firefox, thunderbird, waterfox, ... and disables D-Bus access. Of course we can't add the own rule to firefox-common. Because some program throw errors messages if D-Bus isn't available, but hardfail on D-Bus error due to work policy, I added this for now only to firefox.
Suppose a profile has |
913b373
to
8ab4ab5
Compare
…e.txt See discussion in #3326.
I created a short list about some of the D-Bus addresses.
|
@rusty-snake Awesome, care to toss it in the wiki? |
👍 Definitely something for the wiki. with more comments/descriptions and better formating. What policy should be apply for |
That's one of the reasons I wanted to add an example to the firejail-profile man page. I admit not spending a whole lot of time on it and decided to add an example on how to override a given setting. But for this I would have liked a |
flatpak like: I would say making it opt-in for whitelisting profiles. |
something like
The challenge here is that, as far as I could find, there is no way to pass negative rules to Alternatively, we could just throw an error if a I should really look into how Flatpak handles this. On the other hand, |
I would say |
@glitsj16 Unfortunately, I don't know much about xdg-portals. I think Gnome has some kind of settings dialog for at least flatpak app permissions (filesystem access, webcam, microphone, etc.). I don't know whether that's just black/whitelisting the D-Bus names of portals, or something implemented inside the portals themselves. |
7f4679c
to
cedc7da
Compare
From my side we could merge. |
@rusty-snake LGTM. Great work and a big thank you to all involved! |
* use the new dbus format in chromium-common.profile * use new dbus format in firejail.config Now that #3326 landed I think it might be less confusing to keep using the --nodbus wording. Couldn't come up with a better alternative (yet), so this might need future improvements. * block dbus system bus Blocking the system bus shouldn't affect password functionality etc, as that uses the session bus.
Opening as PR so we can disscuss about them. The most are just extracted from flathub, see #3265 (comment).
EDIT: everyone fell free to push more profiles here.