[17:25] 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] (even though this is Universe, it's still a security question) [17:42] 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] 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] 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] so i'm trying to determine if there's a way OTHER than readwrite to permit access [17:48] sarnold: https://paste.ubuntu.com/p/ybV5pPcwSZ/plain/ is the current apparmor errors [17:48] s/errors/DENIES/ [17:48] but what's odd is I would assume you would *need* bus access to connect to DISPLAY [17:48] and what's MORE odd is non-GNOME environments are the only ones having the error [17:48] works fine in Wayland [17:49] 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] 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] teward: probably not, eg xeyes connects fine and doesn't open dbus.. [17:52] sarnold: on an LXQt environment? [17:52] because this ONLY happens on lubuntu/xubuntu/kubuntu based on testing [17:52] works fine in Wayland/GNOME/MATE [17:52] well i'm testing MATE still [17:53] teward: heh, I can't imagine xeyes cares about the rest of the desktop :) [17:53] 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] (and that abstraction is pulled in in the firefox stuff) [17:56] that sounds like a reasonable thing, yeah [18:26] hmm [18:26] sarnold: looks like I don't have to touch dbus at all, those denies were superfluous [18:26] teward: really? even with file open dialog boxes or similar? [18:26] 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] i'm still testing [18:27] those failures were not what was causing it to not load the GUI [18:27] good good then the world is back togethe ragain :) [18:29] well not really [18:29] sarnold: dbus was needed [18:29] but apparmor is set to DENY access to dconf and /home/ space EXCEPT for where tor browser bundle is launched from [18:29] just so long as it wasn't needed to do X [18:29] sarnold: yeah, dbus wasn't needed to do X but it was needed for dialog [18:29] so i just imported abstractions/dbus-session-strict and fixed *that* call [18:30] but the abstractions/X is being ignored I think [18:30] which is odd [18:39] 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] *cough cough* https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1934005 [18:42] Launchpad bug 1934005 in apparmor (Ubuntu) "abstractions/X: Possible regression of X session functionality by removing 'w' from /tmp/.X11-unix/* line?" [High, New] [18:42] *leaves this for the Security team to dig and handle* [18:48] thanks === JanC_ is now known as JanC