[Bug 1296415] Re: [security] please use apparmor to restrict access to ofono to approved services

Launchpad Bug Tracker 1296415 at bugs.launchpad.net
Thu Jun 26 17:08:41 UTC 2014


This bug was fixed in the package isc-dhcp - 4.2.4-7ubuntu13

---------------
isc-dhcp (4.2.4-7ubuntu13) utopic; urgency=medium

  * apparmor-profile.dhclient: allow signal receive and ptrace readby by
    peer=/usr/sbin/NetworkManager to dhclient and nm-dhcp-client.action
    (LP: #1296415)
 -- Jamie Strandboge <jamie at ubuntu.com>   Wed, 25 Jun 2014 07:05:47 -0500

** Changed in: isc-dhcp (Ubuntu Utopic)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1296415

Title:
  [security] please use apparmor to restrict access to ofono to approved
  services

Status in “indicator-network” package in Ubuntu:
  In Progress
Status in “isc-dhcp” package in Ubuntu:
  Fix Released
Status in “network-manager” package in Ubuntu:
  In Progress
Status in “nuntium” package in Ubuntu:
  In Progress
Status in “ofono” package in Ubuntu:
  In Progress
Status in “powerd” package in Ubuntu:
  In Progress
Status in “ubuntu-download-manager” package in Ubuntu:
  In Progress
Status in “ubuntu-system-settings” package in Ubuntu:
  In Progress
Status in “urfkill” package in Ubuntu:
  In Progress
Status in “indicator-network” source package in Utopic:
  In Progress
Status in “isc-dhcp” source package in Utopic:
  Fix Released
Status in “network-manager” source package in Utopic:
  In Progress
Status in “nuntium” source package in Utopic:
  In Progress
Status in “ofono” source package in Utopic:
  In Progress
Status in “powerd” source package in Utopic:
  In Progress
Status in “ubuntu-download-manager” source package in Utopic:
  In Progress
Status in “ubuntu-system-settings” source package in Utopic:
  In Progress
Status in “urfkill” source package in Utopic:
  In Progress

Bug description:
  It would be useful to limit the services that can connect to ofonod over DBus. We can implement this be creating an otherwise permissive AppArmor profile for ofonod that will limit any DBus calls to ofonod to a list of peer profiles (specifically excluding 'unconfined'). The list of peer profiles is:
   - indicator-network
   - network-manager (and dispatcher.d/03mmsproxy)
   - nuntium
   - telepathy-ofono
   - ofono-scripts
   - powerd
   - ubuntu-download-manager
   - system-settings
   - urfkill

  Each of the above needs to have a profile created for it, adjusting
  the boot scripts as necessary to ensure that the profile is loaded
  before the service starts. The peer profile implementation will be
  wide open as the purpose of the profile is (currently) to simply
  ensure the process of the service has the correct AppArmor labeling
  (though this opens the possibility to confine these services down the
  road if desired).

  Merge requests have been requested for everything except urfkill,
  which has a debdiff attached to this bug. As mentioned, the AppArmor
  profiles for everything except ofonod is wide open so the risk of
  regression is very low for these. In fact, if it is helpful,
  everything except ofono could be uploaded to the archive independently
  and at any time.

  For ofono, as mentioned, the AppArmor profile is also lenient except
  for the policy for its DBus interface. It is critical that ofono is
  updated at the same time or after all the other packages in this bug,
  otherwise any packages that aren't updated will fail to connect to
  ofono.

  I've been running this configuration on my phone for weeks with no
  denials (excepting 03mmsproxy which I adjusted for yesterday). I've
  tested the packaging on x86 emulator to make sure that the profiles
  are installed and loaded properly on boot.

  Test Plan (additional to any existing appropriate test plans)
   1. Install all services on a device
   2. reboot (important to restart the session and any services that aren't
      restarted automatically, like nuntium. reboot is easiest). Note the time
      of the reboot on the device
   3. in addition to any applicable test plans, after full boot:
      adb shell grep DEN /var/log/syslog # there should be no denials for
                                         # ofono after the system boots (there
                                         # likely will be denials during
                                         # upgrade)
      adb shell tail -f /var/log/syslog | grep DEN # run this during all tests
   4. make a call
   5. send a text
   6. send an mms (if possible)
   7. connect to wifi
   8. connect to 3G
   9. download an app
   10. toggle wifi in system-settings
   11. verify ofono-scripts (eg, /usr/share/ofono/scripts/list-modems and 
       /usr/share/ofono/scripts/online-modem
   12. double check `adb shell grep DEN /var/log/syslog` for no ofono denials
       during the testing

  = Original text =
  We should try to find ways to restrict certain properties and interfaces to well known callers, for example Modem 'Online' should be settable by urfkill only. We don't want to allow other processes to set these properties. This would also help to identify if some unintended process is trying to set such properties by accident.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1296415/+subscriptions



More information about the foundations-bugs mailing list