pinlock snap decision potentially allows malicious app to gain access to user PIN and Passcode

[Antti Kaijanmäki]

Currently the pinlock dialog is implemented as snapdecision and thus any application that is allowed to use the notifications can potentially trick the user to provide his PIN code or Passcode to the application by invoking the pinlock dialog.

As we want to allow applications to send normal notifications and snapdecisions we can't just block the whole notify service from them, but also we don't have any means to block just one of them.

Thus the only solution is to remove the pinlock from snap decisions completely and implement a standalone dbus service for pinlock dialog which can be properly confined.

[Mirco Müller (macslow)]

I suggest we do it right this time and have a dedicated service for all security-sensitive dialogs that were wrongly stuffed into notifications. The password-querying notifications should be put in this new service too.

[Michał Sawicz (saviq)]

On 17.04.2014 12:11, Mirco Müller wrote:
> I suggest we do it right this time and have a dedicated service for all
> security-sensitive dialogs that were wrongly stuffed into notifications.
> The password-querying notifications should be put in this new service
> too.

Problem is, as long as these are meant to be part of the notification
stack, they still need to be managed by the same service. Sure, separate
interface, to which only trusted components have access, but this needs
to be managed together nevertheless.

[Matthew Paul Thomas (mpt)]

What does "meant to be part of the notification stack" mean? That sounds like it's assuming the question.

Imagine that ten Skype messages arrive, leading to a 60-second-long queue of notification bubbles on top of the lock screen. As soon as you see the first bubble, you slide the screen to unlock it so you can see any earlier messages and reply. Should Ubuntu wait 60 seconds for the notification bubbles to go away before showing you the PIN dialog? Of course not. The dialog should appear immediately, regardless of what notifications are queued. I don't see why they need to be managed together at all.

[Michał Sawicz (saviq)]

On 29.04.2014 11:28, Matthew Paul Thomas wrote:
> What does "meant to be part of the notification stack" mean? That sounds
> like it's assuming the question.
>
> Imagine that ten Skype messages arrive, leading to a 60-second-long
> queue of notification bubbles on top of the lock screen. As soon as you
> see the first bubble, you slide the screen to unlock it so you can see
> any earlier messages and reply. Should Ubuntu wait 60 seconds for the
> notification bubbles to go away before showing you the PIN dialog? Of
> course not. The dialog should appear immediately, regardless of what
> notifications are queued. I don't see why they need to be managed
> together at all.

Snap decisions / dialogs have priority over standard notifications, so
apart from the fact that a single app can't queue multiple notifications
(and should update the one it has instead), the above would not happen
anyway.

Regardless, system dialogs (for which there is no design btw - they are
all considered snap decisions to date, and PIN/passcode dialog is just
thrown on top), need to interact somehow with notifications and snap
decisions. Maybe block them, maybe only show snap decisions but block
notifications, that needs UX design.

I mentioned some time ago that I believe security-sensitive dialogs need
to look very different from what apps can trigger, so that bugs like
this one are limited. But still there are snap decisions with password
entries in the Notifications spec.

The PIN/passcode is currently implemented as a snap decision (albeit
special), we're missing design guidance on how (and which) "dialogs" are
meant to be special.

[Lars Karlitski (larsu)]

This is a more general bug: an application with access to the notification service should not be able to any notifications other than its own. Even if we had a special thing for system-level stuff (such as pinlock dialogs discussed here), there'd still be privacy implications for applications reading the content of other apps.

Clearly, the freedesktop notification spec is just not up to the task anymore.

[Jamie Strandboge (jdstrand)]

Is this actually an issue for confined apps? Mirco and I looked at this before and I thought there was a separate DBus API for snap decisions. Apps aren't allowed to use snap decisions IIRC, but may use the push-notification-client policy group:

# Description: Can use push notifications as a client
# Usage: common

dbus (receive, send)
     bus=session
     interface=com.ubuntu.PushNotifications
     path=/com/ubuntu/PushNotifications/@{APP_PKGNAME_DBUS}{,/**},

dbus (receive, send)
     bus=session
     interface=com.ubuntu.Postal
     path=/com/ubuntu/Postal/@{APP_PKGNAME_DBUS}{,/**},

Are snap decisions somehow following under the above paths/interfaces?

[Michał Sawicz (saviq)]

To actually display a text entry field or some such they'd have to expose a menumodel elsewhere on dbus and point the notification system at that. Is it possible for confined apps to do that?

[Jamie Strandboge (jdstrand)]

> To actually display a text entry field or some such they'd have to
> expose a menumodel elsewhere on dbus and point the notification system
> at that. Is it possible for confined apps to do that?

What DBus API would be used to achieve this? (I can then check this against policy)

[Jamie Strandboge (jdstrand)]

Mirco, can you answer my question in comment #8?

[Mirco Müller (macslow)]

The DBus-APIs used for exporting these via QMenuModel (Qt/QML-binding for GMenuModel) are:

* org.gtk.Actions
* org.gtk.Menus

[Jamie Strandboge (jdstrand)]

Thanks for the feedback-- though I think we may need more information. Here is the current policy:
  dbus (receive)
       bus=session
       path="/com/canonical/hud/publisher*"
       interface="org.gtk.Menus"
       member="Start",
  dbus (receive)
       bus=session
       path="/com/canonical/hud/publisher*"
       interface="org.gtk.Menus"
       member="End",
  dbus (send)
       bus=session
       path="/com/canonical/hud/publisher*"
       interface="org.gtk.Menus"
       member="Changed"
       peer=(name=org.freedesktop.DBus),
  dbus (receive)
       bus=session
       path="/com/canonical/unity/actions"
       interface=org.gtk.Actions
       member={DescribeAll,Activate},
  dbus (send)
       bus=session
       path="/com/canonical/unity/actions"
       interface=org.gtk.Actions
       member=Changed
       peer=(name=org.freedesktop.DBus),
  dbus (receive)
       bus=session
       path="/context_*"
       interface=org.gtk.Actions
       member="DescribeAll",

Related policy is:
  dbus (send)
       bus=session
       path="/com/canonical/hud"
       interface="org.freedesktop.DBus.Properties"
       member="GetAll",
  dbus (send)
       bus=session
       path="/com/canonical/hud"
       interface="com.canonical.hud"
       member="RegisterApplication",
  dbus (receive, send)
       bus=session
  dbus (receive)
       bus=session
       path="/com/canonical/hud"
       interface="com.canonical.hud"
       member="UpdatedQuery",
  dbus (receive)
       bus=session
       interface="com.canonical.hud.Awareness"
       member="CheckAwareness",

My understanding was that apps were *not* supposed to be allowed to use snap decisions, which is why Mirco had me add this policy:
  audit deny dbus bus=session
                  interface="com.canonical.snapdecisions",

Can this policy be circumvented? If yes, can someone demonstrate how? If not, are you saying that the push notifications dialogs can be used to fake the pinlock dialog? If so, moving the pin lock snap decision to another service will not solve this and the only way to solve that would be to make sure that the pinlock snap decision looks sufficiently visually different and that applications can't influence a push notification to look like it.

[Jamie Strandboge (jdstrand)]

Shoot, I had a mispaste of the related policy. Here is all of it for clarity:

  dbus (send)
       bus=session
       path="/com/canonical/hud"
       interface="org.freedesktop.DBus.Properties"
       member="GetAll",
  dbus (send)
       bus=session
       path="/com/canonical/hud"
       interface="com.canonical.hud"
       member="RegisterApplication",
  dbus (receive, send)
       bus=session
       path=/com/canonical/hud/applications/@{APP_ID_DBUS}*,
  dbus (receive)
       bus=session
       path="/com/canonical/hud/publisher*"
       interface="org.gtk.Menus"
       member="Start",
  dbus (receive)
       bus=session
       path="/com/canonical/hud/publisher*"
       interface="org.gtk.Menus"
       member="End",
  dbus (send)
       bus=session
       path="/com/canonical/hud/publisher*"
       interface="org.gtk.Menus"
       member="Changed"
       peer=(name=org.freedesktop.DBus),
  dbus (receive)
       bus=session
       path="/com/canonical/unity/actions"
       interface=org.gtk.Actions
       member={DescribeAll,Activate},
  dbus (send)
       bus=session
       path="/com/canonical/unity/actions"
       interface=org.gtk.Actions
       member=Changed
       peer=(name=org.freedesktop.DBus),
  dbus (receive)
       bus=session
       path="/context_*"
       interface=org.gtk.Actions
       member="DescribeAll",
  dbus (receive)
       bus=session
       path="/com/canonical/hud"
       interface="com.canonical.hud"
       member="UpdatedQuery",
  dbus (receive)
       bus=session
       interface="com.canonical.hud.Awareness"
       member="CheckAwareness",
...
  audit deny dbus bus=session
                  interface="com.canonical.snapdecisions",

[Jamie Strandboge (jdstrand)]

I am going to mark this as "incomplete". Antii says "Currently the pinlock dialog is implemented as snapdecision and thus any application that is allowed to use the notifications can potentially trick the user to provide his PIN code or Passcode to the application by invoking the pinlock dialog." However, AppArmor policy explicitly disables the snapdecisions interface and there is no code or described methodology describing the problem so I can't determine if this is mere concern that there might be a problem or that there is an actual problem.

[Jamie Strandboge (jdstrand)]

Bumping the priority since this would be a bad bug. Marking as rtm14 since we can't have apps phish for passwords.

[kevin gunn (kgunn72)]

so is this not a bug after all ?
assigning to antti in case he has a test case.

[Mirco Müller (macslow)]

Extracting the whole snap-decision functionality into a separate dialog service, which would be easier to isolate, feels like a too large effort for rtm, considering the other fires we've to put out still.

Admittedly I've not done a thorough analysis of the expected effort yet. But it will require major changes in lp:unity-notifications, lp:unity8, all the numerous snap-decision using apps, the new dialog-service itself and of course new Design guidelines for how such a service would fit in the current notification-concept.

Before such an effort should be started the exact functional requirements need to be ironed out, so we avoid having to fix things up as we implement it... like it happened with snap-decision notifications, which got loaded with more and more typical dialog-like features as we went along.

All of the above will additionally also require new qml/AP-tests and of course user- and integration-testing.

That's all I can say in a short comment.

[Launchpad Janitor (janitor)]

[Expired for unity-notifications because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for unity8 (Ubuntu) because there has been no activity for 60 days.]