On 02/09/2025 20.07, James Meyer wrote:
> I wanted to let you folks know this.
>
> amnesia@amnesia:~$ cat /etc/apparmor.d/local/usr.bin.thunderbird
>
> Shows nothing
>
> The Thunderbird apparmor profile via cat /etc/apparmor.d/
> usr.bin.thunderbird shows that it does not block reading the files
> under `/sys/class/net` and `/sys/devices/virtual/dmi/id/`
>
> The presence of /**/ r, (plus the surrounding broad / r, and /usr/** r,
> lines) is the concrete part of the profile that “grants read access to
> essentially the whole filesystem”,
IMHO the really bad part is `owner @{HOME}/[^.]** rw,` which gives
read-write access to the user's files. The rest of the filesystem is not
very interesting...
> making the MAC‑address files under
> `sys/class/net` and the DMI files under `/sys/devices/virtual/dmi/id/`
> reachable by Thunderbird correct?
... except some stuff like this. I'm sure the maintainer of the AppArmor
profiles would love it if you sent some patches improving the blocklist
or even replacing the too permissive `/**/ r` rule with something more
sensible (at Tails we would appreciate it!):
https://gitlab.com/apparmor/apparmor-profiles
> I don't see a later deny in the profile that overrides it to essentially
> blocking read access to these two paths?
>
> Why does Tor Browser aa profile block access but not Thunderbird? Why
> shouldn't the profile be any different for Thunderbird in this regard?
Because no one has done the work, which isn't as simple as "add a bunch
of lines to the AppArmor profile to block all the things" because then
Thunderbird will become unusable. It has to be done in tandem with
making Thunderbird able to use Desktop Portals to mediate filesystem
access, like Tails does for Tor Browser, which isn't trivial:
https://gitlab.tails.boum.org/tails/tails/-/issues/19592
Cheers!
