apparmor profile for gpsd

@ubuntu-security: it would be great if someone could give the profile a security POV pre-check

@paelzer - from my experience with gpsd that looks pretty good regarding the file rules etc - hopefully someone else who is more intimately familiar with AppArmor can comment on the list of capabilities.

Looks good to me, thanks Christian.

FYI - I'll work on this along with some other gpsd activities related to the planned MIR.
But that will be 19.04 material and not urgent right now..

@Seth - thanks for the profile review

Jan 30 13:28:49 Dell-2018 sudo[135379]: jamesb : TTY=pts/1 ; PWD=/home/jamesb/ntpsec ; USER=root ; COMMAND=/usr/sbin/gpsdctl add /dev/ttyUSB0
Jan 30 13:28:49 Dell-2018 sudo[135379]: pam_unix(sudo:session): session opened for user root by jamesb(uid=0)
Jan 30 13:28:49 Dell-2018 gpsdctl[135380]: gpsd_control(action=add, arg=/dev/ttyUSB0)
Jan 30 13:28:49 Dell-2018 gpsdctl[135380]: reached a running gpsd
Jan 30 13:28:49 Dell-2018 audit[135224]: AVC apparmor="DENIED" operation="file_perm" profile="/usr/sbin/gpsd" name="/run/gpsd.sock" pid=135224 comm="gpsd" requested_mask="r" denied_mask="r" fsuid=124 ouid=0
Jan 30 13:28:49 Dell-2018 audit[135224]: AVC apparmor="DENIED" operation="file_perm" profile="/usr/sbin/gpsd" name="/run/gpsd.sock" pid=135224 comm="gpsd" requested_mask="r" denied_mask="r" fsuid=124 ouid=0
Jan 30 13:28:49 Dell-2018 sudo[135379]: pam_unix(sudo:session): session closed for user root

I can not add /dev/ttyUSB0 to a running gpsd either automatically or manually (on prerelease 20.04) when the AppArmor profile is active. Disabling it allows manual controls to work.

I can reproduce this by running:

sudo gpsdctl add /dev/ttyUSB0

even without a /dev/ttyUSB0 device being present. We can then resolve the AppArmor denial by adding something like:

  /{,var/}run/gpsd.sock rw,

to the AppArmor profile - so that this remains if the package provided profile gets replaced on a package upgrade, please try adding the above line to the file /etc/apparmor.d/local/usr.sbin.gpsd and then reload the AppArmor profile by running

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.gpsd

And finally then see if you can add the device as expected. If this resolves the issue then I suggest this be added to the standard GPSD AppArmor profile via an SRU.

That does not seem to be it. There seems to be a leaky avstraction somewhere.

Are there any additional AppArmor denials in dmesg?

I tested the rule it works fine.

There are no additional issues because the subsequent access of the daemon to the device is covered already.
  # common serial paths to GPS devices
  /dev/tty{,S,USB,AMA,ACM}[0-9]* rw,

Prepped, Tested and submitted to Debian as https://salsa.debian.org/debian-gps-team/pkg-gpsd/merge_requests/3

This package is a sync, so if the update in Debian is in time we have to do nothing.
Otherwise we can still upload this as a fix post feature-freeze for 20.04

This bug was fixed in the package gpsd - 3.20-4

---------------
gpsd (3.20-4) unstable; urgency=medium

  [ Christian Ehrhardt ]
  * [58b18a53] apparmor: fix control socket usage for gpsdctrl (LP: #1790496)
    The subsequent access of the daemon to the device is covered already.
      # common serial paths to GPS devices
      /dev/tty{,S,USB,AMA,ACM}[0-9]* rw,
    But gpsdctl itself isn't yet - therefore we see
      $ sudo gpsdctl add /dev/ttyUSB0
    triggering:
      apparmor="DENIED profile="/usr/sbin/gpsd" name="/run/gpsd.sock" requested_mask="r" denied_mask="r"
    This change adds a rule for that.
    Signed-off-by: Christian Ehrhardt <email address hidden>

 -- Bernd Zeimetz <email address hidden> Sat, 01 Feb 2020 01:11:24 +0100