Dear Simon McVittie, Thank you for your feedback and for taking the time to analyze the issue.
> The AppArmor profile is part of the papers package, though, so > reassigning to a package that doesn't contain the AppArmor profile > doesn't really make sense. You are right, I was mistaken. This bug indeed belongs to the "papers" package, since the AppArmor profile file is included directly in that package at: https://salsa.debian.org/gnome-team/papers/-/blob/debian/latest/debian/apparmor-profile > If you change these lines to > > audit owner @{HOME}/.pki/** lrk, > audit /sys/devices/** r, > audit /run/pcscd/pcscd.comm rw, > > and reboot (or reload AppArmor), then try to sign something, what > accesses get logged to the audit log? Without those lines, running `sudo dmesg` shows the errors below and GNOME Papers fails to sign the document. --------------------------------------- audit: type=1400 audit(1762484197.772:138): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.772:139): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.772:140): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:02.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.772:141): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:02.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.772:142): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.772:143): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.772:144): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:02.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.772:145): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:02.0/uevent" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.776:146): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/vendor" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484197.776:147): apparmor="DENIED" operation="open" class="file" profile="/usr/bin/papers" name="/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:00.0/0000:03:00.0/device" pid=11258 comm="papers" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 audit: type=1400 audit(1762484221.112:221): apparmor="DENIED" operation="file_lock" class="file" profile="/usr/bin/papers" name="/home/user/.pki/nssdb/cert9.db" pid=11258 comm="papers" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000 [...previous line repeated 8 times...] --------------------------------------- With those corrected lines added, and after restarting AppArmor using sudo `systemctl restart apparmor`, GNOME Papers signs the document normally and no further error messages appear. > I agree with commenters on the Ubuntu bug that "/sys/devices/** r," > seems like overly broad access, but probably it can be narrowed down > somewhat. I agree as well, but it is difficult to determine how this rule could be narrowed, because other systems may have different devices with different paths. A more restrictive rule might end up being too specific to my setup. Therefore, I cannot say which exact paths should be restricted. According to the log I sent, GNOME Papers attempts to access two different paths under: "/sys/devices/pci0000:00" In addition, as described in Message #5 by Jose Ramon Alvarez-Sanchez, his setup also requires access to "/home/user/.mozilla/firefox/", which does not appear in my case, so his environment is slightly different from mine as well. > Ideally the apparmor package would have an abstraction for "access to > smart cards" or similar, which papers' profile could "include" instead > of having to know all the details of how smart cards are accessed. It would indeed be a good solution, but I don’t have the knowledge at the moment to work on something like that. The workaround I provided addresses my specific case and is sufficient for my setup, but creating a proper abstraction in the AppArmor package would certainly be the ideal long-term approach. I also ended up creating bug #1120163, reporting the same issue, although I am not entirely sure whether it should be considered a duplicate of this one, despite the similarities. In that report, I used `reportbug --template papers`, which includes some additional information specific to my setup. If possible, please check whether that bug should be closed or kept separate. If you need any additional information or testing from my side, feel free to let me know. Thank you again for your time and assistance. Best regards, Cristiano Fraga G. Nunes
