- The first is D-Bus session abstractions.
There are D-Bus denies for opening dialog boxes and file open boxes, which need D-Bus abstractions to access the user sessions. Fixed by including abstractions/dbus-session (which also implicitly imports abstractions/dbus-session-strict for systemd user sessions) in the AppArmor rules, if the abstractions exist.
The abstractions/dbus-session rule also requires adding an AppArmor owner rule for the ~/.cache/ibus/dbus-* socket. Otherwise, keyboard input will stop working.
- The second is X abstractions.
Observed initially in #588, systems that do NOT have GNOME installed on them, such as Lubuntu which uses LXQt and has ZERO GNOME components, will have issues accessing X11 sockets.
In such systems, the implied abstractions/gnome already part of the AppArmor profile do not exist. Therefore, AppArmor will not import abstractions/gnome which includes the X abstractions because the GNOME abstractions definition does not exist.
In such cases, components of the UI will not properly function with dialog boxes. This is why this is separately explicitly required, despite GNOME abstractions including X abstractions.
According to https://github.com/torproject/torbrowser-launcher/pull/716
the definition of `gnupg_import_ok_pattern` in
`torbrowser_launcher/common.py` is causing some warnings.
But it looks like it is not being used since
83fa1d38c4, so we can remove it.
Thanks to meator for reporting the issue.
We already allow ptrace for its relevant subprocesses via ptrace
rules, and I'm unsure if the full capability is really needed. I see
lots of other profiles which have ptrace rules without the capability
so I guess not. And I wonder if allowing the capability allows ptrace
for arbitrary processes, which would be really bad.
So let's assume it's not needed and we'll see what happens.
Firefox adjusts the OOM scores of its processes so that if they are
reaped they are killed in a sane order, e.g. the parent process last.
Source: hal/linux/LinuxProcessPriority.cpp
