This bug was fixed in the package gpsd - 3.20-8ubuntu0.1
---
gpsd (3.20-8ubuntu0.1) focal; urgency=medium
* d/usr.sbin.gpsd: improve apparmor rules for PPS usage
(LP: #1872175 LP: #1872178)
-- Christian Ehrhardt Thu, 30 Apr
2020 12:40:23 +0200
** Changed in: gpsd (Ubuntu Fo
As expected before the fix I wasn't able to use any PPS.
Upgrading to gpsd 3.20-8ubuntu0.1 worked without any further breakage.
We see on upgrade that the apparmor profile is replaced:
[12408.110277] audit: type=1400 audit(1589444818.093:34): apparmor="STATUS"
operation="profile_replace" profile
FYI - I'll verify this tomorrow morning once I've freed up another system.
For the sake of completeness I want to check this on another arch than where I
wrote the fixes. TO ensure this really helps in a generic way.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Hello Mark, or anyone else affected,
Accepted gpsd into focal-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/gpsd/3.20-8ubuntu0.1
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubun
Waiting in Focal-unapproved since yesterday - FYI autopkgtest sniff
tests are good as well in
https://bileto.ubuntu.com/excuses/4047/focal.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Ti
The auto-sync in groovy also included 3.20-8/3.20-9 which covers this
issue here:
gpsd (3.20-10) unstable; urgency=medium
[ Christian Ehrhardt ]
* [7670b61e] exchange gpsd-client/tools content
* [fb81a96a] examples also need to be in -clients instead of -tools then
* [7f8d06a8] d/control[
This bug was fixed in the package gpsd - 3.20-11
---
gpsd (3.20-11) unstable; urgency=medium
[ Christian Ehrhardt ]
* [232c8d73] d/rules: fix ubxtool to use python3 in the gpsd package (LP:
#1878158)
Signed-off-by: Christian Ehrhardt
-- Bernd Zeimetz Tue, 12 May 2020 13:
** Also affects: chrony (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: gpsd (Ubuntu Focal)
Importance: Undecided
Status: New
** No longer affects: chrony (Ubuntu)
** No longer affects: chrony (Ubuntu Focal)
--
You received this bug notification because yo
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/gpsd/+git/gpsd/+merge/383405
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
gpsd unable to open chrony
** Description changed:
- GPSd fails to access the socket used to communicate PPS signals with
- Chrony.
+ [Impact]
+
+ * Current GPSD apparmor isolation is too strict to use PPS devices
+properly.
+
+ * backport changes we added to 20.10 to fix this
+
+
+ [Test Case]
+
+ * Set up a P
Looks great. As an aside, this is exactly why we investigate where the
accesses are coming from. If we didn't, gpsd would've been allowed to
read potentially sensitive data of other processes and load kernel
modules (yikes!).
Thank you for sticking with it :)
--
You received this bug notificatio
FYI - fix submitted as part of PR https://salsa.debian.org/debian-gps-
team/pkg-gpsd/-/merge_requests/5
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
gpsd unable to open chrony PPS so
In the meantime I also was able to track down that sys_ptrace was for
fusercount.
So no adding that was ok, since it triggers only a few times (even seems to be
only once per reboot) I'm not sure about adding a denial - it is not as
log-filling as the other case was.
I further debugged for the
> # required for pps initialization
> capability dac_read_search,
> capability sys_time,
> /sys/devices/virtual/pps/ r,
> # to submit data to chrony
> ptrace read peer=/usr/sbin/chronyd,
> # for libusb
> /sys/devices/**/usb[0-9]*/** r,
> # triggered on fusercount, not strictly required and unsafe t
Further tests completed, all good with the new rules.
Waiting for salsa to be back up to propose the apparmor changes to
Bernd.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
gpsd una
Ok, it seems after eliminating the above issue the sys_ptrace isn't triggered
anymore.
And even if it is it seems not required for the functionality and would be
rather unsafe.
Until I get a GPS lock chrony sees:
chronyc> sources
210 Number of sources = 10
MS Name/IP address Stratum Poll
Note, give it time and it will be happy with PPS at better accuracy.
chronyc> sources
210 Number of sources = 10
MS Name/IP address Stratum Poll Reach LastRx Last sample
===
#x GPS
Overall rules to go with seems to be
# required for pps initialization
capability dac_read_search,
capability sys_time,
/sys/devices/virtual/pps/ r,
# to submit data to chrony
ptrace read peer=/usr/sbin/chronyd,
# for libusb
/sys/devices/**/usb[0-9]*/** r,
# triggered on fusercount, not s
The next critical one was cap "sys_ptrace", that comes from another part
of the code but also isn't strictly required for functionality. Let us
understand why that is triggered.
That one seems to be even more interesting.
It does trigger under gdb, but not when single stepped to find where it
ori
Essentially the check iterates over all /proc/
And there it does readlink to check if any has the target open.
In my example if any FD is a link to /dev/ttyUSB0
But this already is "graceful" the apparmor deny to
readlink(fdpath, linkpath, sizeof(linkpath)
is
apparmor="DENIED" operation="ptrac
The only "bad rule" is for ptrace/unconfined but I'm not sure what to do
about it.
This is the backtrace that will trigger all ptrace/read calls.
"just" an open to /dev/ttyUSB0 with mode=2 and flags => (mode | O_NONBLOCK |
O_NOCTTY).
#0 __libc_open64 (file=0xb026c300 "/dev/ttyUSB0",
oflag
** Attachment added: "gpsd strace"
https://bugs.launchpad.net/ubuntu/+source/gpsd/+bug/1872175/+attachment/5361911/+files/gpsd.strace
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
** Attachment added: "caps trace"
https://bugs.launchpad.net/ubuntu/+source/gpsd/+bug/1872175/+attachment/5361910/+files/gpsd.caps
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
gp
I was tracing caps and syscalls for the security Team.
$ while ! pidof gpsd; do sleep 0.001; done; sudo capable-bpfcc -K -p $(pidof
gpsd)
...
Does not report anything.
The same without -p and runnign through gpsd init is better.
CAP_DAC_READ_SEARCH is from some /proc access and the ptrace seems
@paelzer per the proposed fix in #7 you can stick my sign-off on it.
Signed-off-by: John Johansen
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
gpsd unable to open chrony PPS socket
After a discussion with jjohansen (thanks!) I learned that some of the
procfs access will trigger ptrace rules. Odd, but nice to know ...
After that was clear I was fixing he initial fail. I found a bunch of
further issues hidden behind those but it seems at least in my local
setup the following m
@Mark, I know it is unlikely you find the time for it this week.
But if you can - modifying the files in /etc/apparmor.d and retrying might help
to test this on more devices.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bug
unfortunately the kernel actually uses ptrace_access_check for more than
just ptrace, and the LSM (and hence apparmor) is not given context as to
where the check is coming from. The current full list that can trigger
an apparmor ptrace check is below. We can discard any that are not using
a variant
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'
If GPSD tries to contact chrony I see entries like this:
gpsd[2649]: gpsd:PROG: PPS:/dev/ttyAMA0 chrony socket
/var/run/chrony.ttyAMA0.sock doesn't exist
gpsd[2649]: gpsd:PROG: PPS:/dev/ttyUSB1 chrony socket
/var/run/chrony.ttyUSB1.sock doesn't exist
I reduced it to just the device that seem
>From some local debugging, without PPS the code is not trying to reach
this path that I'd need to debug, so this is blocked by
https://bugs.launchpad.net/ubuntu/+source/gpsd/+bug/1872178/comments/2
as well.
I'll debug this further once I have a a device here.
** Changed in: gpsd (Ubuntu)
Hmm, I wanted to debug the init_hook function on my system to check the details.
Also my setup won't fail the same way as yours, it just doesn't try to connect
- it did in the Bionic past, but that was on a different (now broken) system.
But also:
gpsd-clients-dbgsym : Depends: gpsd-clients (=
** Tags added: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
gpsd unable to open chrony PPS socket
To manage notifications about this bug go to:
https://bugs.launchpad.ne
For the sake of apparmor rules being sometimes odd, there is no "other"
apparmor denial in your dmesg around that time is there?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1872175
Title:
gpsd una
34 matches
Mail list logo
