date:20150205

[Touch-packages] [Bug 1362469] Re: AppArmor unrequested reply protection generates unallowable denials

2015-02-05 Thread Tyler Hicks

Also important to note is that this bug is no longer considered to be a
blocker when syncing the RTM archive with the Vivid packages. Outside of
the noisy denial message, the fact that AppArmor is blocking unrequested
replies should not result in any breakage of software relying on D-Bus
communications.

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

Title:
  AppArmor unrequested reply protection generates unallowable denials

Status in dbus package in Ubuntu:
  In Progress

Bug description:
  Starting with utopic's dbus 1.8.6-1ubuntu1 package, the new AppArmor
  unrequested reply protections can generate some denials that can't
  easily be allowed in policy. For example, when running a confined
  pasaffe, you see these denials when starting and closing pasaffe:

  apparmor=DENIED operation=dbus_error  bus=session
  error_name=org.freedesktop.DBus.Error.UnknownMethod mask=send
  name=:1.22 pid=4993 profile=/usr/bin/pasaffe peer_pid=3624
  peer_profile=unconfined

  It isn't obvious how to construct an AppArmor D-Bus rule to allow that
  operation. A bare dbus, rule allows it but that's not acceptable for
  profiles implementing tight D-Bus confinement.

  The code that implements unrequested reply protections should be
  reviewed for issues and, if everything looks good there,
  investigations into how to allow the operation that triggers the above
  denial should occur.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1362469/+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

[Touch-packages] [Bug 1362469] Re: AppArmor unrequested reply protection generates unallowable denials

2015-02-05 Thread Tyler Hicks

I now have a good understanding of the problem as well as a standalone
reproducer. The issue stems from the NO_REPLY_EXPECTED flag in the
message header. When the sender of a message sets the NO_REPLY_EXPECTED
flag, it means tells the recipient that a reply, either in the form of a
method_return or an error message, is not needed even if the method
normally provides a reply message. The D-Bus spec
(http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages)
does not require that the receiver of the message honor the
NO_REPLY_EXPECTED flag. Here's the text:

  ... the reply can be omitted as an optimization. It is compliant with
   this specification to return the reply despite this flag, although
   doing so on a bus with a non-trivial security policy (such as the
   well-known system bus) may result in access denial messages being
   logged for the reply.

The dbus-daemon code has a mechanism for tracking whether or not a reply
message (method_return and error messages) is a reply that the sender of
the original message actually asked for. If the reply message was not
requested, the dbus-daemon code treats it as an unrequested reply.
This is important to the AppArmor mediation code in dbus-daemon because
it lets reply messages that *were* requested through without requiring
any sort of AppArmor policy query. The thought is that the AppArmor
security policy allowed the original message to go through so surely the
security policy author expects any corresponding reply message to go
through. That all works great except for when the original message has
the NO_REPLY_EXPECTED flag. The dbus-daemon code treats any replies to
that message as an unrequested reply. That means that it is subject to
the AppArmor policy and may be rejected if the process sending the reply
does not have send permissions.

The bug description for this bug mentions an AppArmor denial of pasaffe
sending an UnknownMethod error message to an unconfined process:

apparmor=DENIED operation=dbus_error bus=session
  error_name=org.freedesktop.DBus.Error.UnknownMethod mask=send
  name=:1.22 pid=4993 profile=/usr/bin/pasaffe peer_pid=3624
  peer_profile=unconfined

What is happening there is that some unconfined UI component (global
menus backend?) is communicating with the UI components of the confined
pasaffe process over D-Bus. The confined UI components are tearing
themselves down after the user enters their master password into a
pasaffe modal dialog box and presses Ok. This results in the confined
UI components unregistering the D-Bus object path corresponding to the
modal dialog box. After this happens, the unconfined UI components are
attempting to send one last message, with the NO_REPLY_EXPECTED flag
set, to the confined UI components (the End method call). This is an
error condition since the D-Bus object has already been unregistered.
The gdbus (glib) bindings notice that this is an error and send an
UnknownMethod error message reply, despite the fact that the
NO_REPLY_EXPECTED flag was set on the original message. This causes
dbus-daemon to treat the reply as an unrequested reply and the AppArmor
mediation code blocks the message and generates a denial message.

Outside of the noisy denial message, there is no harm in this. The
original sender of the message stated that a reply was not needed and
the gdbus bindings went ahead and sent an error reply message, which is
fine according to the D-Bus spec. The spec even warns that complex
security policy may result in a denial message for such a reply.

We could patch the gdbus bindings to not send an error reply message in
this situation but I'm not sure upstream would accept such a patch and
there may be other bindings or services that ignore the
NO_REPLY_EXPECTED flag.

In the lp1362469.tar.gz attachment, I have two example services (one
written against the python-dbus bindings and the other against the gdbus
bindgs) that demonstrate that these unrequested reply denials can come
from a service, too. If you gunzip it, untar it, and run 'make', it'll
test both services. It will result in two denials:

apparmor=DENIED operation=dbus_method_return  bus=session
  mask=send name=:1.154 pid=21732 profile=service peer_pid=21734
  peer_profile=unconfined
apparmor=DENIED operation=dbus_error  bus=session
  error_name=org.freedesktop.DBus.Error.UnknownMethod mask=send
  name=:1.154 pid=21732 profile=service peer_pid=21734
  peer_profile=unconfined

The second denial is the same sort of denial as the pasaffe denial that
I described above. The first denial is an example of a service receiving
a message with the NO_REPLY_EXPECTED flag set and still returning a
reply message. This also results in an unrequested reply denial.

I think this shows that it is unreasonable to try to fix every D-Bus
binding, service, and client that ignores the NO_REPLY_EXPECTED flag in
order to allow or quiet these types of denials.

Our policy language doesn't allow us to easily allow or quiet the

[Touch-packages] [Bug 993298] Re: Please make NetworkManager-controlled dnsmasq respect /etc/hosts

2015-02-05 Thread Sonia Hamilton

+1 affects me.

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

Title:
Please make NetworkManager-controlled dnsmasq respect /etc/hosts

Status in network-manager package in Ubuntu:
Confirmed

Bug description:
Since 12.04 NetworkManager uses the dnsmasq plugin by default to
resolve DNS requests. Unfortunately the dnsmasq plug-in has --no-
hosts, etc. hard coded [1] which means (among other things) that after
the upgrade to 12.04 /etc/hosts will no longer be used to resolve DNS
requests. This changes the prior behavior of NetworkManager without
any visible warning to the end user. AFAICS there's no other way to
work around this problem as to manually revert the change and disable
the dnsmasq plug-in in the NetworkManager config, see [2,3]:

To turn off dnsmasq in Network Manager, you need to edit
/etc/NetworkManager/NetworkManager.conf and comment the 'dns=dnsmasq'
line then do a 'sudo restart network-manager'.

This is of course not a bug in the NetworkManager which just behaves
as intended. The problem is in the change of the configuration of the
Ubuntu packaging which will probably leave many wondering why their
/etc/hosts suddenly no longer works. This cost me considerable time to
debug and probably is a usability problem for others, too.

Maybe you could provide a more visible documentation than that in [3]?
E.g., *including a comment in /etc/hosts that explains the change* and
how to work around it would have saved me a lot of time. It would have
automatically alerted me on upgrade as manual changes to /etc/hosts
would then have triggered a prompt while leaving those users with
standard /etc/hosts in peace.

Probably similar problems arise with other disabled config files and
could be alerted to the users? Thinking of resolv.conf, etc.

[1]
http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dnsmasq-manager/nm-dnsmasq-manager.c,
line 285
[2] i.e. http://ubuntuforums.org/showthread.php?t=1968061
[3] http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/993298/+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

[Touch-packages] [Bug 1413458] Re: Intermittent Intel GPU Lockup: intel_crtc_wait_for_pending_flips

2015-02-05 Thread Timo Aaltonen

technically it's a kernel bug but moving to -intel for now so we can
track it better

** Package changed: mesa (Ubuntu) = xserver-xorg-video-intel (Ubuntu)

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

Title:
  Intermittent Intel GPU Lockup: intel_crtc_wait_for_pending_flips

Status in xserver-xorg-video-intel package in Ubuntu:
  Incomplete

Bug description:
  Sometimes when playing a video (VLC) or browsing in chromium, the
  display stops updating except for the mouse pointer. Audio playback
  will continue. I can press ctrl-alt-F1 to get to another VT (though
  there is a delay of ~10 seconds before this occurs) and then switch
  back and things seem fine. I see this in the syslog after it's
  occurred:

  Jan 21 21:52:33 sydney kernel: [365284.305075] CPU: 7 PID: 1567 Comm: Xorg 
Tainted: GW 3.16.0-29-generic #39-Ubuntu
  Jan 21 21:52:33 sydney kernel: [365284.305077] Hardware name: Dell Inc. 
OptiPlex 9010/051FJ8, BIOS A19 08/18/2014
  Jan 21 21:52:33 sydney kernel: [365284.305079]  0009 
8803f9cebbf8 8278218a 
  Jan 21 21:52:33 sydney kernel: [365284.305083]  8803f9cebc30 
8206fedd  8804039fc000
  Jan 21 21:52:33 sydney kernel: [365284.305086]  880403788210 
880403ae6000 880403ae6000 8803f9cebc40
  Jan 21 21:52:33 sydney kernel: [365284.305089] Call Trace:
  Jan 21 21:52:33 sydney kernel: [365284.305097]  [8278218a] 
dump_stack+0x45/0x56
  Jan 21 21:52:33 sydney kernel: [365284.305102]  [8206fedd] 
warn_slowpath_common+0x7d/0xa0
  Jan 21 21:52:33 sydney kernel: [365284.305106]  [8206ffba] 
warn_slowpath_null+0x1a/0x20
  Jan 21 21:52:33 sydney kernel: [365284.305129]  [c061608c] 
intel_crtc_wait_for_pending_flips+0x16c/0x180 [i915]
  Jan 21 21:52:33 sydney kernel: [365284.305134]  [820b9730] ? 
prepare_to_wait_event+0x100/0x100
  Jan 21 21:52:33 sydney kernel: [365284.305155]  [c0618b53] 
intel_crtc_disable_planes+0x33/0x1c0 [i915]
  Jan 21 21:52:33 sydney kernel: [365284.305174]  [c0619120] 
ironlake_crtc_disable+0x50/0x980 [i915]
  Jan 21 21:52:33 sydney kernel: [365284.305193]  [c0559f53] ? 
drm_modeset_lock+0x33/0xf0 [drm]
  Jan 21 21:52:33 sydney kernel: [365284.305197]  [82787f72] ? 
mutex_lock+0x12/0x30
  Jan 21 21:52:33 sydney kernel: [365284.305217]  [c061a4e7] 
intel_crtc_update_dpms+0x67/0xa0 [i915]
  Jan 21 21:52:33 sydney kernel: [365284.305237]  [c061eb59] 
intel_connector_dpms+0x59/0x70 [i915]
  Jan 21 21:52:33 sydney kernel: [365284.305253]  [c0550e19] 
drm_mode_obj_set_property_ioctl+0x399/0x3a0 [drm]
  Jan 21 21:52:33 sydney kernel: [365284.305267]  [c0550e50] 
drm_mode_connector_property_set_ioctl+0x30/0x40 [drm]
  Jan 21 21:52:33 sydney kernel: [365284.305278]  [c053fa4f] 
drm_ioctl+0x1df/0x680 [drm]
  Jan 21 21:52:33 sydney kernel: [365284.305284]  [8222009c] ? 
fsnotify+0x27c/0x350
  Jan 21 21:52:33 sydney kernel: [365284.305287]  [8222009c] ? 
fsnotify+0x27c/0x350
  Jan 21 21:52:33 sydney kernel: [365284.305291]  [821f5208] 
do_vfs_ioctl+0x2c8/0x4a0
  Jan 21 21:52:33 sydney kernel: [365284.305295]  [821e3701] ? 
__sb_end_write+0x31/0x60
  Jan 21 21:52:33 sydney kernel: [365284.305299]  [821e1272] ? 
vfs_write+0x1b2/0x1f0
  Jan 21 21:52:33 sydney kernel: [365284.305302]  [821f5461] 
SyS_ioctl+0x81/0xa0
  Jan 21 21:52:33 sydney kernel: [365284.305306]  [8278a1ad] 
system_call_fastpath+0x1a/0x1f
  Jan 21 21:52:33 sydney kernel: [365284.305309] ---[ end trace 
491ebdb18d4be6c4 ]---

  ProblemType: Bug
  DistroRelease: Ubuntu 14.10
  Package: libgl1-mesa-dri 10.3.2-0ubuntu0.1
  ProcVersionSignature: Ubuntu 3.16.0-29.39-generic 3.16.7-ckt2
  Uname: Linux 3.16.0-29-generic x86_64
  .tmp.unity.support.test.0:
   
  ApportVersion: 2.14.7-0ubuntu8.1
  Architecture: amd64
  CompizPlugins: 
[core,composite,opengl,decor,move,place,grid,mousepoll,session,snap,vpswitch,wall,neg,obs,compiztoolbox,regex,imgpng,resize,gnomecompat,animation,expo,ezoom,workarounds,unitymtgrabhandles,screenshot,fade,scale,unityshell]
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  CurrentDesktop: Unity
  Date: Wed Jan 21 21:55:30 2015
  DistUpgraded: Fresh install
  DistroCodename: utopic
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller 
[8086:0162] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Dell Device [1028:052c]
  InstallationDate: Installed on 2014-11-29 (53 days ago)
  InstallationMedia: Ubuntu 14.10 Utopic Unicorn - Release amd64 (20141022.1)
  MachineType: Dell Inc. OptiPlex 9010
  ProcKernelCmdLine:

[Touch-packages] [Bug 1418808] [NEW] Group messages not received (Ubuntu Phone)

2015-02-05 Thread jtd

Public bug reported:

Device: mako
Release: Ubuntu Phone 14.10 (r13)
Package: Messaging
Expectation: When another user's mobile phone sends a group message that 
includes my phone number, I expect to receive that group message.
Reality: Others on the group message list receive the message, I do not.

** Affects: messaging-app (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: avengers

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

Title:
  Group messages not received (Ubuntu Phone)

Status in messaging-app package in Ubuntu:
  New

Bug description:
  Device: mako
  Release: Ubuntu Phone 14.10 (r13)
  Package: Messaging
  Expectation: When another user's mobile phone sends a group message that 
includes my phone number, I expect to receive that group message.
  Reality: Others on the group message list receive the message, I do not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/messaging-app/+bug/1418808/+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

1 2 3 4 >

1 - 100 of 351 matches

Mail list logo