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.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity8 in Ubuntu.
https://bugs.launchpad.net/bugs/1306769

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

Status in Server and client library for desktop notifications in Unity:
  Triaged
Status in “unity8” package in Ubuntu:
  Triaged

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity-notifications/+bug/1306769/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to