dx-packages team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

Public bug reported:

We discussed DBus APIs in relation to application confinement in various places and decided that services that require DBus mediation, click packaging and apparmor should all agree on how to derive an application-specific DBus path. The concept of the APP_ID is central to click, the SDK, application lifecycle, apparmor and DBus services that applications use. The APP_ID is of the form:
$pkgname_$appname_$version

and this is derived from the click manifest. Eg:
  com.ubuntu.dropping-letters_dropping-letters_0.1.2.2

Application lifecycle will export the APP_ID to the environment. The click-apparmor hook creates the @{APP_ID_DBUS} variable in apparmor policy for use in dbus rules. click-apparmor uses nih_dbus_path() from libnih-dbus to generate the @{APP_ID_DBUS}. Eg, for com.ubuntu.dropping-letters_dropping-letters_0.1.2.2, we would have:
  @{APP_ID_DBUS}="com_2eubuntu_2edropping_2dletters_5fdropping_2dletters_5f0_2e1_2e2_2e2"

This allows us to have rules like this in apparmor policy:
  dbus (send)
      bus=session
      path="/com/canonical/hud/applications/@{APP_ID_DBUS}",

However, the HUD is generating a different value for its path, as seen in this dbus apparmor denial:
dbus[3390]: apparmor="DENIED" operation="dbus_method_call"  bus="session" name=":1.641" path="/com/canonical/hud/applications/com_ubuntu_dropping_letters_dropping_letters_0_1_2_2" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" pid=23875 profile="com.ubuntu.dropping-letters_dropping-letters_0.1.2.2" peer_pid=22913 peer_profile="unconfined"

We need the hud and apparmor to agree, otherwise we have to use policy
that's much too lenient where malicious applications can interfere with
other apps. Please adjust the hud to use libnih-dbus. Attached is a test
C program to demonstrate how to do this.

** Affects: hud (Ubuntu)
     Importance: High
         Status: Triaged

** Affects: hud (Ubuntu Saucy)
     Importance: High
         Status: Triaged


** Tags: application-confinement appstore

** Attachment added: "test-nih.c"
   https://bugs.launchpad.net/bugs/1218107/+attachment/3792285/+files/test-nih.c

** Description changed:

  We discussed DBus APIs in relation to application confinement in various places and decided that services that require DBus mediation, click packaging and apparmor should all agree on how to derive an application-specific DBus path. The concept of the APP_ID is central to click, the SDK, application lifecycle, apparmor and DBus services that applications use. The APP_ID is of the form:
  $pkgname_$appname_$version
  
  and this is derived from the click manifest. Eg:
-   com.ubuntu.dropping-letters_dropping-letters_0.1.2.2
+   com.ubuntu.dropping-letters_dropping-letters_0.1.2.2
  
  Application lifecycle will export the APP_ID to the environment. The click-apparmor hook creates the @{APP_ID_DBUS} variable in apparmor policy for use in dbus rules. click-apparmor uses nih_dbus_path() from libnih-dbus to generate the @{APP_ID_DBUS}. Eg, for com.ubuntu.dropping-letters_dropping-letters_0.1.2.2, we would have:
-   @{APP_ID_DBUS}="com_2eubuntu_2edropping_2dletters_5fdropping_2dletters_5f0_2e1_2e2_2e2"
+   @{APP_ID_DBUS}="com_2eubuntu_2edropping_2dletters_5fdropping_2dletters_5f0_2e1_2e2_2e2"
  
  This allows us to have rules like this in apparmor policy:
-   dbus (send)
-       bus=session
-       path="/com/canonical/hud/applications/@{APP_ID_DBUS}",
+   dbus (send)
+       bus=session
+       path="/com/canonical/hud/applications/@{APP_ID_DBUS}",
  
  However, the HUD is generating a different value for its path, as seen in this dbus apparmor denial:
  dbus[3390]: apparmor="DENIED" operation="dbus_method_call"  bus="session" name=":1.641" path="/com/canonical/hud/applications/com_ubuntu_dropping_letters_dropping_letters_0_1_2_2" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" pid=23875 profile="com.ubuntu.dropping-letters_dropping-letters_0.1.2.2" peer_pid=22913 peer_profile="unconfined"
  
- Please adjust the hud to use libnih-dbus. Attached is a test C program
- to demonstrate how to do this.
+ We need the hud and apparmor to agree, otherwise we have to use policy
+ that's much too lenient where malicious applications can interfere with
+ other apps. Please adjust the hud to use libnih-dbus. Attached is a test
+ C program to demonstrate how to do this.

** Also affects: hud (Ubuntu Saucy)
   Importance: Undecided
       Status: New

** Changed in: hud (Ubuntu Saucy)
       Status: New => Triaged

** Changed in: hud (Ubuntu Saucy)
   Importance: Undecided => High

** Tags added: application-confinement appstore

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to hud in Ubuntu.
https://bugs.launchpad.net/bugs/1218107

Title:
  hud should use APP_ID and libnih to generate the DBus path

Status in “hud” package in Ubuntu:
  Triaged
Status in “hud” source package in Saucy:
  Triaged

Bug description:
  We discussed DBus APIs in relation to application confinement in various places and decided that services that require DBus mediation, click packaging and apparmor should all agree on how to derive an application-specific DBus path. The concept of the APP_ID is central to click, the SDK, application lifecycle, apparmor and DBus services that applications use. The APP_ID is of the form:
  $pkgname_$appname_$version

  and this is derived from the click manifest. Eg:
    com.ubuntu.dropping-letters_dropping-letters_0.1.2.2

  Application lifecycle will export the APP_ID to the environment. The click-apparmor hook creates the @{APP_ID_DBUS} variable in apparmor policy for use in dbus rules. click-apparmor uses nih_dbus_path() from libnih-dbus to generate the @{APP_ID_DBUS}. Eg, for com.ubuntu.dropping-letters_dropping-letters_0.1.2.2, we would have:
    @{APP_ID_DBUS}="com_2eubuntu_2edropping_2dletters_5fdropping_2dletters_5f0_2e1_2e2_2e2"

  This allows us to have rules like this in apparmor policy:
    dbus (send)
        bus=session
        path="/com/canonical/hud/applications/@{APP_ID_DBUS}",

  However, the HUD is generating a different value for its path, as seen in this dbus apparmor denial:
  dbus[3390]: apparmor="DENIED" operation="dbus_method_call"  bus="session" name=":1.641" path="/com/canonical/hud/applications/com_ubuntu_dropping_letters_dropping_letters_0_1_2_2" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" pid=23875 profile="com.ubuntu.dropping-letters_dropping-letters_0.1.2.2" peer_pid=22913 peer_profile="unconfined"

  We need the hud and apparmor to agree, otherwise we have to use policy
  that's much too lenient where malicious applications can interfere
  with other apps. Please adjust the hud to use libnih-dbus. Attached is
  a test C program to demonstrate how to do this.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hud/+bug/1218107/+subscriptions