Clearly some apparmor hits are going on even though not too much details can be seen here.
apparmor="DENIED" operation="ptrace" profile="/usr/sbin/gpsd" pid=2600 comm="gpsd" requested_mask="read" denied_mask="read" peer="unconfined"
Chrony as one potential candidate is confined as well, ...
I'm discussing with the security Team what this might try to reach and how to improve. Might not be the actual root cause here, but worth to track down.
In complain mode they do not bring any other rules:
apparmor="ALLOWED" operation="ptrace" profile="/usr/sbin/gpsd" pid=2987 comm="gpsd" requested_mask="read" denied_mask="read" peer="unconfined"
But it makes it work.
Not only does it get the socket connect to chrony (this bug) but also the intialization of PPS seems apparmor related. Here GPSD init logs with default and complain apparmor.
==> gpsd.aa.log <==
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)
gpsd:PROG: PPS:/dev/ttyUSB0 connect chrony socket failed: /var/run/chrony.ttyUSB0.sock, error: -2, errno: 13/Permission denied
gpsd:INFO: KPPS:/dev/ttyUSB0 device not found.
gpsd:WARN: KPPS:/dev/ttyUSB0 kernel PPS unavailable, PPS accuracy will suffer
gpsd:PROG: PPS:/dev/ttyUSB0 thread launched
gpsd:INFO: PPS:/dev/ttyUSB0 ntpshm_link_activate: 1
gpsd:INFO: device /dev/ttyUSB0 activated
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 112
==> gpsd.noaa.log <==
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)
gpsd:INFO: KPPS:/dev/ttyUSB0 RFC2783 path:/dev/pps1, fd is 9
gpsd:INFO: KPPS:/dev/ttyUSB0 pps_caps 0x1133
gpsd:INFO: KPPS:/dev/ttyUSB0 have PPS_CANWAIT
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS will be used
gpsd:INFO: PPS:/dev/ttyUSB0 ntpshm_link_activate: 1
gpsd:INFO: device /dev/ttyUSB0 activated
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 112
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: startup at 2020-04-27T14:43:19.000Z (1587998599)
gpsd:INFO: /dev/ttyUSB0 identified as type u-blox, 1 sec @ 9600bps
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: PPS:/dev/ttyUSB0 Clear hooks called clock: 1587998611.999974735 real: 1587998611.000000000: accepted
I need to talk with the security Team even more.
Maybe the pps access ioctl or such is misdetected as ptrace?
And from there things go south ...?
Clearly some apparmor hits are going on even though not too much details can be seen here. "/usr/sbin/ gpsd" pid=2600 comm="gpsd" requested_ mask="read" denied_mask="read" peer="unconfined"
apparmor="DENIED" operation="ptrace" profile=
Chrony as one potential candidate is confined as well, ...
I'm discussing with the security Team what this might try to reach and how to improve. Might not be the actual root cause here, but worth to track down.
In complain mode they do not bring any other rules: "ALLOWED" operation="ptrace" profile= "/usr/sbin/ gpsd" pid=2987 comm="gpsd" requested_ mask="read" denied_mask="read" peer="unconfined"
apparmor=
But it makes it work.
Not only does it get the socket connect to chrony (this bug) but also the intialization of PPS seems apparmor related. Here GPSD init logs with default and complain apparmor.
==> gpsd.aa.log <== chrony. ttyUSB0. sock, error: -2, errno: 13/Permission denied link_activate: 1
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)
gpsd:PROG: PPS:/dev/ttyUSB0 connect chrony socket failed: /var/run/
gpsd:INFO: KPPS:/dev/ttyUSB0 device not found.
gpsd:WARN: KPPS:/dev/ttyUSB0 kernel PPS unavailable, PPS accuracy will suffer
gpsd:PROG: PPS:/dev/ttyUSB0 thread launched
gpsd:INFO: PPS:/dev/ttyUSB0 ntpshm_
gpsd:INFO: device /dev/ttyUSB0 activated
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 112
==> gpsd.noaa.log <== link_activate: 1 27T14:43: 19.000Z (1587998599) 999974735 real: 1587998611. 000000000: accepted
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)
gpsd:INFO: KPPS:/dev/ttyUSB0 RFC2783 path:/dev/pps1, fd is 9
gpsd:INFO: KPPS:/dev/ttyUSB0 pps_caps 0x1133
gpsd:INFO: KPPS:/dev/ttyUSB0 have PPS_CANWAIT
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS will be used
gpsd:INFO: PPS:/dev/ttyUSB0 ntpshm_
gpsd:INFO: device /dev/ttyUSB0 activated
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 112
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: startup at 2020-04-
gpsd:INFO: /dev/ttyUSB0 identified as type u-blox, 1 sec @ 9600bps
gpsd:INFO: KPPS:/dev/ttyUSB0 kernel PPS timeout unknown error
gpsd:INFO: PPS:/dev/ttyUSB0 Clear hooks called clock: 1587998611.
I need to talk with the security Team even more.
Maybe the pps access ioctl or such is misdetected as ptrace?
And from there things go south ...?