[Bug 722815] Re: apparmor prevents ntp from reading gpsd

[Kees Cook]

Thanks for tracking this down! Unfortunately, ipc_owner is a rather
strong capability (allows access to all shared memory), and it looks
like ntpd expects to actually write to the memory region (e.g.
"shm->valid = 0" is in the code), so SHM_RDONLY doesn't seem viable
either. Instead, I've added a note to the AppArmor profile itself
pointing people to the right option if they want to enable it for their
local system (since it doesn't seem appropriate to do this by default
for all ntpd users).

** Changed in: ntp (Ubuntu)
       Status: Confirmed => Fix Committed

** Changed in: ntp (Ubuntu)
     Assignee: (unassigned) => Kees Cook (kees)

** Changed in: ntp (Ubuntu)
   Importance: Low => Wishlist

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is a direct subscriber.
https://bugs.launchpad.net/bugs/722815

Title:
  apparmor prevents ntp from reading gpsd

Status in “ntp” package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: ntp

  Ubuntu 10.10
  ntp 1:4.2.4p8+dfsg-1ubuntu6

  With gpsd installed and a USB GPS device plugged in, xgps shows that
  GPS data is available, but "ntpq -p" does not display it. "server" and
  "fudge" lines had already been added to /etc/ntp.conf & ntp restarted.

  /etc/apparmor.d/usr.sbin.ntpd needs to have 1 line added, "capability
  ipc_owner," (after the line "capability ipc_lock,") and then apparmor
  and ntp need to be restarted. "ntpq -p" then shows the time obtained
  from the GPS.

  The man page for shmat(2) indicates that EACCES is returned if the
  process lacks CAP_IPC_OWNER. Perhaps if ntp requested access with
  SHM_RDONLY, owner capability might not be required? Does adding
  "capability ipc_owner," open a security hole?