| 2013-08-28 23:06:33 |
Jamie Strandboge |
bug |
|
|
added bug |
| 2013-08-28 23:06:33 |
Jamie Strandboge |
attachment added |
|
test-nih.c https://bugs.launchpad.net/bugs/1218107/+attachment/3792285/+files/test-nih.c |
|
| 2013-08-28 23:07:54 |
Jamie Strandboge |
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"
Please adjust the hud to use libnih-dbus. Attached is a test C program to demonstrate how to do this. |
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. |
|
| 2013-08-28 23:07:58 |
Jamie Strandboge |
nominated for series |
|
Ubuntu Saucy |
|
| 2013-08-28 23:07:58 |
Jamie Strandboge |
bug task added |
|
hud (Ubuntu Saucy) |
|
| 2013-08-28 23:08:05 |
Jamie Strandboge |
hud (Ubuntu Saucy): status |
New |
Triaged |
|
| 2013-08-28 23:08:08 |
Jamie Strandboge |
hud (Ubuntu Saucy): importance |
Undecided |
High |
|
| 2013-08-28 23:08:20 |
Jamie Strandboge |
tags |
|
application-confinement appstore |
|
| 2013-09-03 16:01:03 |
Jamie Strandboge |
attachment added |
|
hud_13.10.1+13.10.20130822.4-0ubuntu2.debdiff https://bugs.launchpad.net/ubuntu/+source/hud/+bug/1218107/+attachment/3801119/+files/hud_13.10.1%2B13.10.20130822.4-0ubuntu2.debdiff |
|
| 2013-09-03 16:18:34 |
Ubuntu Foundations Team Bug Bot |
tags |
application-confinement appstore |
application-confinement appstore patch |
|
| 2013-09-03 21:35:15 |
Jamie Strandboge |
hud (Ubuntu Saucy): status |
Triaged |
In Progress |
|
| 2013-09-03 21:37:16 |
Jamie Strandboge |
branch linked |
|
lp:~jdstrand/hud/hud-lp1218107 |
|
| 2013-09-04 02:32:10 |
Jamie Strandboge |
hud (Ubuntu Saucy): assignee |
|
Jamie Strandboge (jdstrand) |
|
| 2013-09-04 05:18:25 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/saucy-proposed/hud |
|
| 2013-09-05 11:45:24 |
Launchpad Janitor |
hud (Ubuntu Saucy): status |
In Progress |
Fix Released |
|
| 2013-09-05 16:17:01 |
Manuel de la Peña |
bug |
|
|
added subscriber Manuel de la Peña |
| 2013-09-16 18:56:06 |
Jamie Strandboge |
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. |
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. For click, the APP_ID is of the form (on converged, all this still applies, the APP_ID is just something like '$appname', eg 'gedit'):
$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. |
|
