1441894 - Snap apparmor denial binding to dbus

Status: UNCONFIRMED

(Release Engineering :: Release Automation: Snap, defect, minor)

Description

[Ken VanDine]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.88 Chrome/65.0.3325.88 Safari/537.36

Steps to reproduce:

Running the snap generates these errors:

apparmor="DENIED" operation="dbus_bind"  bus="session" name="org.mozilla.firefox.V29yaw__" 
mask="bind" pid=25893 label="snap.firefox.firefox". It should use the dbus interface slot to bind to this path

Comment 1

[Ken VanDine]

We can use the dbus interface to allow the snap to bind to a well known dbus name.  Firefox is appending a seemingly random string to the name.  In this example it's "org.mozilla.firefox.V29yaw__".  Can anyone help answer why this needed?

Comment 2

[Johan Lorenzo [:jlorenzo] - On PTO - Back on August 26th]

I couldn't find who's may be in charge of GTK's DBus. Would you have an idea, Mike?

Comment 3

[Mike Kaply [:mkaply]]

Martin Stransky. And it appears it's this bug?

https://bugzilla.mozilla.org/show_bug.cgi?id=1418770

Comment 4

[Ken VanDine]

(In reply to Mike Kaply [:mkaply] from comment #3)
> Martin Stransky. And it appears it's this bug?
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1418770

That shouldn't be related.  It fails to bind to the interface silently right now.  We can tell snap it's allowed to bind to the name, but I think it needs a well-known name, like org.mozilla.firefox.  I'm asking our security team if there's a way to allow a wildcard like "org.mozilla.firefox.*".

Comment 5

[Mike Kaply [:mkaply]]

I'm confused. Is this a new problem? I'm wondering why it wasn't found before.

There were multiple changes related to dbus:

https://hg.mozilla.org/mozilla-central/log/tip/widget/xremoteclient/DBusRemoteClient.cpp

This particular change (appending the profile directory) is about allowing multiple copies of Firefox to run at the same time.

Comment 6

[Ken VanDine]

I'm trying to figure out what exactly isn't working.  Currently apparmor is denying the request to bind to the dbus name.  So effectively the DBusRemoteClient stuff is just failing silently.  Everything seems to behave just fine, even when launching a second instance with a second profile.  They both seem to work fine, but I could be missing something.  I guess it's just gracefully falling back as if there is no dbus session available.  

Can you describe what functionality we lose by not having the dbus binding?

Comment 7

[Martin Stránský [:stransky]]

(In reply to Ken VanDine from comment #1)
> We can use the dbus interface to allow the snap to bind to a well known dbus
> name.  Firefox is appending a seemingly random string to the name.  In this
> example it's "org.mozilla.firefox.V29yaw__".  Can anyone help answer why
> this needed?

The appendix "V29yaw__" is encoded (due to DBus limitations) Firefox profile - you can have more than one active Firefox instance running.

The DBus Remote service is actively utilized by Wayland backend only - we may add an option to disable it when running under snap.

Comment 8

[Ken VanDine]

(In reply to Martin Stránský [:stransky] from comment #7)
> (In reply to Ken VanDine from comment #1)
> > We can use the dbus interface to allow the snap to bind to a well known dbus
> > name.  Firefox is appending a seemingly random string to the name.  In this
> > example it's "org.mozilla.firefox.V29yaw__".  Can anyone help answer why
> > this needed?
> 
> The appendix "V29yaw__" is encoded (due to DBus limitations) Firefox profile
> - you can have more than one active Firefox instance running.
> 
> The DBus Remote service is actively utilized by Wayland backend only - we
> may add an option to disable it when running under snap.

Our security team suggested perhaps you could use the same well-known dbus name and differentiate the profiles with different paths.  That way we could still safely confine the snap and still allowing access to bind to the dbus name.

Thoughts?

Comment 9

[Martin Stránský [:stransky]]

(In reply to Ken VanDine from comment #8)
> 
> Our security team suggested perhaps you could use the same well-known dbus
> name and differentiate the profiles with different paths.  That way we could
> still safely confine the snap and still allowing access to bind to the dbus
> name.
> 
> Thoughts?

Well, I can review such patch if you write one.

Comment 10

[Ken VanDine]

(In reply to Martin Stránský [:stransky] from comment #9)
> (In reply to Ken VanDine from comment #8)
> > 
> > Our security team suggested perhaps you could use the same well-known dbus
> > name and differentiate the profiles with different paths.  That way we could
> > still safely confine the snap and still allowing access to bind to the dbus
> > name.
> > 
> > Thoughts?
> 
> Well, I can review such patch if you write one.

Great, we'll work on that.

Comment 11

[Liz Henry (:lizzard)]

Looks like this is not ready for 59.

Comment 12

[Johan Lorenzo [:jlorenzo] - On PTO - Back on August 26th]

I just confirmed with Canonical this bug is minor and has no user impact. They are okay to release 59.0 without it fixed.