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

After discussion with Jamie, I think we merely want to restrict ofono usage to a particular set of system processes.

AppArmor is not capable of restricting individual properties, and unfortunately "Online" is a property of the top-level org.ofono.Modem interface which we really can't restrict to just urfkill.

Our current plan of record is that we will provide basic unrestrictive AppArmor profiles to the following system/session processes:

- NetworkManager
- telepathy-ofono ( or related telepathy process/component )
- urfkill
- indicator-network
- nuntium ( MMS daemon )
- powerd

We also need some further investigation as the following components *may* also need access:

- ubuntu-download-manager
- greeter

The greeter code itself probably doesn't need its own access to ofono, but if you are basing any checks on which user is running, please remember that telepathy-ofono and friends run as the 'lightdm' user inside a greeter session.

Looks like rild will also need a profile. Furthermore, we need to create the symlinks in /etc/apparmor/init/network-interface-security to make sure these things are coming up confined.

I think I was wrong about rild and was hitting another issue.

I seem to have this all working locally by creating profiles for:
  usr.bin.nuntium
  usr.bin.powerd
  usr.bin.system-settings
  usr.lib.indicator-network-service
  usr.lib.urfkilld
  usr.sbin.NetworkManager
  usr.sbin.ofonod

then adjusting these upstart jobs to load the profile prior to launch (I may end up adjusting all the upstart jobs to be sure):
  ofono.conf
  powerd.conf
  urfkill.conf

To demonstrate what this looks like, the ofonod profile has:
# Permissive profile limit dbus access
/usr/sbin/ofonod (attach_disconnected) {
...

  # We can do anything on dbus
  dbus (bind, send),

  # Some methods are ok by anyone (ie, dbus-daemon itself)
  dbus (receive)
       bus=system
       interface="org.freedesktop.DBus.Properties",

  # Limit who can connect on DBus to processes with these apparmor labels (LP: #1296415)
  dbus (receive) peer=(label=/usr/lib/*/indicator-network/indicator-network-service),
  dbus (receive) peer=(label=/usr/sbin/NetworkManager),
  dbus (receive) peer=(label=/usr/bin/nuntium),
  dbus (receive) peer=(label=/usr/bin/powerd),
  dbus (receive) peer=(label=/usr/bin/system-settings),
  dbus (receive) peer=(label=/usr/lib/*/urfkill/urfkilld),
  dbus (receive) peer=(label=/usr/lib/telepathy/telepathy-ofono),
  dbus (receive) peer=(label=ofono_scripts),
...
}

profile ofono_scripts /usr/share/ofono/scripts/* (attach_disconnected) {
  capability,
  mount,
  remount,
  umount,
  network,
  dbus,
  ptrace,
  signal,

  / rwkl,
  /** rwlkmix,
}

All of the peers have permissive profiles ala the 'ofono_scripts' policy above. Each then gets an apparmor label for it, and the ofonod apparmor policy allows connections from only those labels (not even unconfined can connect). Light testing shows that 'list-modems' and 'online-modem' from /usr/share/ofono/scripts work fine and on reboot the phone comes up and connects to 3G and generally seems to work ok. indicator-network and settings all work correctly when switching back and forth between wifi and 3g). Toggling cellular data works.

I did notice that ubuntu-download-manager gets a denial:
Jun 4 10:19:42 ubuntu-phablet dbus[756]: apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.ofono.Manager" member="GetModems" name=":1.77" mask="receive" pid=1350 profile="/usr/sbin/ofonod" peer_pid=4086 peer_profile="unconfined"
Jun 4 10:19:42 ubuntu-phablet dbus[756]: message repeated 16 times: [ apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.ofono.Manager" member="GetModems" name=":1.77" mask="receive" pid=1350 profile="/usr/sbin/ofonod" peer_pid=4086 peer_profile="unconfined"]

# ps auxww|grep 4086
root 4086 2.0 0.4 65996 7776 ? Sl 10:19 0:00 /usr/bin/ubuntu-download-manager

Should ubuntu-download-manager be added to the list?

I just added a task for ubuntu-download-manager. Nice catch. Please let me know when you're ready for some more hands-on testing.

So, I have things working locally, but there is a problem in that a race condition is being hit (LP: #1305108) where telepathy-ofono is launching before their profile is loaded, which breaks the dialer (since the process is running under the 'unconfined' label which isn't allowed to talk to ofono). Basically, I think we need bug #1305108 fixed before we can proceed with this.

AppArmor packages are in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages to unblock this bug. I'm testing local modifications for this bug with those packages now and everything works well. We will be requesting a silo for the apparmor packages on monday. As such, I will be preparing MRs for this bug then.

FYI, /etc/NetworkManager/dispatcher.d/03mmsproxy also needs to talk to ofono. This is actually called by /usr/lib/NetworkManager/nm-dispatcher.action as opposed to /usr/sbin/NetworkManager and /etc/NetworkManager/dispatcher.d/03mmsproxy is shipped by lxc-android-config. This isn't a problem, but I think I'd prefer to keep that policy in with the network manager packaging rather than shipping an apparmor profile in lxc-android-config.

I'll be attaching debdiffs for review and also proposing merge requests.

Ok, at this point I am handing off to Phonedations to perform the landing. I've updated the description for testing, risk, implementation, etc and I believe everything is in place and am of course available for questions.

Ok, I made a small change to the policy in the MRs so I deleted the debdiffs since they aren't that useful now that I linked the MRs to this bug. Attached is an updated debdiff for urfkill.

Adding an isc-dhcp task. It doesn't need to talk to ofono, but dhclient is confined and the dhclient profile needs to allow receiving signals and ptrace reads by /usr/sbin/NetworkManager.

indicator-network-autopilot needs to talk to ofono directly.
inside lp:indicator-network tree see tests/autopilot/indicator_network/helpers/phonesim_manager.py

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 <email address hidden> Wed, 25 Jun 2014 07:05:47 -0500

Removed the "rtm14" tag based on Jamie's NOTE in the bug description.

Bumped Importance to WishList as it's clear this will not be fixed for RTM.

Adjusted the bug statuses based on the updated description. This is "Won't Fix" for Utopic ("Triaged" when "V" opens).