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",
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.
Thanks for the feedback-- though I think we may need more information. Here is the current policy:
path="/ com/canonical/ hud/publisher* "
interface= "org.gtk. Menus"
member= "Start" ,
path="/ com/canonical/ hud/publisher* "
interface= "org.gtk. Menus"
member= "End",
path="/ com/canonical/ hud/publisher* "
interface= "org.gtk. Menus"
member= "Changed"
peer=(name= org.freedesktop .DBus),
path="/ com/canonical/ unity/actions"
interface= org.gtk. Actions
member= {DescribeAll, Activate} ,
path="/ com/canonical/ unity/actions"
interface= org.gtk. Actions
member= Changed
peer=(name= org.freedesktop .DBus),
path="/ context_ *"
interface= org.gtk. Actions
member= "DescribeAll" ,
dbus (receive)
bus=session
dbus (receive)
bus=session
dbus (send)
bus=session
dbus (receive)
bus=session
dbus (send)
bus=session
dbus (receive)
bus=session
Related policy is:
path="/ com/canonical/ hud"
interface= "org.freedeskto p.DBus. Properties"
member= "GetAll" ,
path="/ com/canonical/ hud"
interface= "com.canonical. hud"
member= "RegisterApplic ation",
path="/ com/canonical/ hud"
interface= "com.canonical. hud"
member= "UpdatedQuery" ,
interface= "com.canonical. hud.Awareness"
member= "CheckAwareness ",
dbus (send)
bus=session
dbus (send)
bus=session
dbus (receive, send)
bus=session
dbus (receive)
bus=session
dbus (receive)
bus=session
My understanding was that apps were *not* supposed to be allowed to use snap decisions, which is why Mirco had me add this policy:
interface= "com.canonical. snapdecisions" ,
audit deny dbus bus=session
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.