[17:25] <teward> who here knows what the security risks are of letting an application connect / readwrite from an AppArmor perspective to /run/user/{gid,uid}/bus?  Because torbrowser-launcher on non-GNOME Ubuntu variants (Kubuntu, Lubuntu, Xubuntu) Impish don't run without readwrite to that apparmor rule, and I want to think about the security risks before I push that as a possible fix.
[17:26] <teward> (even though this is Universe, it's still a security question)
[17:42] <sarnold> teward: if the dbus the user is using doesn't do any apparmor enforcement, that's a "let the tor browser ask any application on the session bus to do anything that they advertise that they can do"
[17:43] <sarnold> teward: if the dbus the user is using does apparmor enforcement, then the dbus calls, signals, replies, etc, ought to be mediated as described by policy
[17:47] <teward> sarnold: right, but right now in non-GNOME environments, the underlying Tor Browser Firefox can't connect to the bus, and can't connect to display :0 and hard segfaults
[17:47] <teward> so i'm trying to determine if there's a way OTHER than readwrite to permit access
[17:48] <teward> sarnold: https://paste.ubuntu.com/p/ybV5pPcwSZ/plain/ is the current apparmor errors
[17:48] <teward> s/errors/DENIES/
[17:48] <teward> but what's odd is I would assume you would *need* bus access to connect to DISPLAY
[17:48] <teward> and what's MORE odd is non-GNOME environments are the only ones having the error
[17:48] <teward> works fine in Wayland
[17:49] <teward> so unless htere's some included apparmor abstraction or something that is GNOME specific that would grant readwrite to the bus, I'm confused
[17:50] <teward> sarnold: do you know if there is a requirement to read/write to the bus to make sure display can be connected to for an application?
[17:52] <sarnold> teward: probably not, eg xeyes connects fine and doesn't open dbus..
[17:52] <teward> sarnold: on an LXQt environment?
[17:52] <teward> because this ONLY happens on lubuntu/xubuntu/kubuntu based on testing
[17:52] <teward> works fine in Wayland/GNOME/MATE
[17:52] <teward> well i'm testing MATE still
[17:53] <sarnold> teward: heh, I can't imagine xeyes cares about the rest of the desktop :)
[17:53] <teward> i found a dbus-session-strict policy for `owner /run/user/[0-9]*/bus rw,` in abstractions/dbus-session-strict... wonder if we should be pulling this in because that's a rule for systemd with enable-user-sessions
[17:53] <teward> (and that abstraction is pulled in in the firefox stuff)
[17:56] <sarnold> that sounds like a reasonable thing, yeah
[18:26] <teward> hmm
[18:26] <teward> sarnold: looks like I don't have to touch dbus at all, those denies were superfluous
[18:26] <sarnold> teward: really? even with file open dialog boxes or similar?
[18:26] <teward> i DID see an asplosion on /tmp/.X11-unix/X0 though, where it needs readwrite and apparently doesn't listen to the X abstractions if i include those
[18:26] <teward> i'm still testing
[18:27] <teward> those failures were not what was causing it to not load the GUI
[18:27] <sarnold> good good then the world is back togethe ragain :)
[18:29] <teward> well not really
[18:29] <teward> sarnold: dbus was needed
[18:29] <teward> but apparmor is set to DENY access to dconf and /home/ space EXCEPT for where tor browser bundle is launched from
[18:29] <sarnold> just so long as it wasn't needed to do X
[18:29] <teward> sarnold: yeah, dbus wasn't needed to do X but it was needed for dialog
[18:29] <teward> so i just imported abstractions/dbus-session-strict and fixed *that* call
[18:30] <teward> but the abstractions/X is being ignored I think
[18:30] <teward> which is odd
[18:39] <teward> huh looks like maybe a permissions change on abstractions/X which removes 'w' from the unix sockets in /tmp/.X11-unix/* which is... odd.
[18:42] <teward> *cough cough* https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1934005
[18:42] <teward> *leaves this for the Security team to dig and handle*
[18:48] <sarnold> thanks