[Merge] lp:~thomas-voss/location-service/fix-1219164 into lp:location-service

[Thomas Voß]

> The AppArmor policies are being looked up by pid which can be a racy
> interface. Do the races matter to us? Will something else in the system
> prevent the following chain of events?
> 
> A process with pid 4242 running with AppArmor profile Foo makes a location
> request
> A process dies from some event
> B process with any pid spawns children until one has pid 4242
> C process with pid 4242 running with AppArmor profile Bar receives permission
> to use location from previous request
> 
> It seems fairly unlikely, I'll admit, but if an attacker can chew up enough
> CPU time, some race conditions can become arbitrarily easy to exploit.
> 

It's a very good point. To address it, I would propose:

  (1.) Query pid*, uid*, apparmor* profile from dbus daemon
  (2.) Query agent
  (3.) Query pid, uid, apparmor and compare to pid*, uid*, apparmor*

Issue and task is captured here: https://bugs.launchpad.net/location-service/+bug/1352978. However, I would think that we should land the MP as is to make sure we have fixed the critical RTM bug.
> Thanks
-- 
https://code.launchpad.net/~thomas-voss/location-service/fix-1219164/+merge/228861
Your team Ubuntu Phablet Team is subscribed to branch lp:location-service.