Comment 13 for bug 1872175

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=0xaaaab026c300 <devices+6080> "/dev/ttyUSB0", oflag=2306)
    at ../sysdeps/unix/sysv/linux/open64.c:37
#1 0x0000aaaab01f87b8 in open (__oflag=2306,
    __path=0xaaaab026c300 <devices+6080> "/dev/ttyUSB0")
    at /usr/include/aarch64-linux-gnu/bits/fcntl2.h:57
#2 gpsd_serial_open (session=0xaaaab026ab40 <devices>) at serial.c:528
#3 0x0000aaaab01ed934 in gpsd_open (session=0xaaaab026ab40 <devices>) at libgpsd_core.c:558
#4 0x0000aaaab01ede54 in gpsd_activate (session=0xaaaab026ab40 <devices>, mode=2)
    at libgpsd_core.c:567
#5 0x0000aaaab01d32cc in open_device (device=0xaaaab026ab40 <devices>) at gpsd.c:686
#6 0x0000aaaab01d4798 in gpsd_add_device (flag_nowait=<optimized out>,
    device_name=<optimized out>) at gpsd.c:746
#7 gpsd_add_device (device_name=0xffffeadb485b "/dev/ttyUSB0", flag_nowait=<optimized out>)
    at gpsd.c:715
#8 0x0000aaaab01cf664 in main (argc=6, argv=0xffffeadb4408) at gpsd.c:2139

So on this kind of device it seems glibc/kernel throw that in.

I discussed with #security and it seems there is no great way out that seems worth the effort - gladly the rest of the profile keeps it a bit in line and it is only a read rule.

The odd thing there is that the open call seems to call back to fusercount.
Due to -O2 this is a bit unprecise and inlined but it seems that is is.

I need to teach it to recognize an "apparmor can't access" from a real fail.
Then I could keep it forbidden (and therefore safer) but have the init work.