Revisiting wide default permissions

[jos128]

Hi,

I don't think Zoom is trust-worthy software, so I welcomed the snap sandboxing layer provided here. However I think the default snap interface permissions are unnecessary permissive.

This is a request for revisiting issue #4.

@ogra1 wrote:

system-observe and hardware-observe are also not technically required to get zoom basically running but prevent people from running out of diskspace because their logs are filled with gigabtes of apparmor denials ;) check yourself with dmesg -w | grep zoom while these two are disconnected and then running zoom from another terminal ...

This is in fact not the case (anymore).

user@host> snap connections | grep zoom
audio-playback            zoom-client:audio-playback                :audio-playback                  manual
audio-record              zoom-client:audio-record                  :audio-record                    manual
desktop                   zoom-client:desktop                       :desktop                         -
network                   zoom-client:network                       :network                         manual
network-bind              zoom-client:network-bind                  :network-bind                    manual
opengl                    zoom-client:opengl                        :opengl                          manual
unity7                    zoom-client:unity7                        :unity7                          -
wayland                   zoom-client:wayland                       :wayland                         -
x11                       zoom-client:x11                           :x11                             -

user@host> sudo dmesg --clear
user@host> dmesg -Tw | grep zoom > dmesg_out
...

Zoom appears to write merely 4.1kB (less than 20 lines) on each zoom-client launch, and that seems to be all of it. (See snap store bug below.)

I think removing the system-observe and hardware-observe interface would be a good idea, as these are advised accessible in trusted applications only, as stated by snap API docs.

Zoom had frequent severe security and privacy issues, is proprietary software and would be pretty much recommended against, if it wasn't the de facto standard for video conferencing and hardly avoidable for 2020's people. Installing it at all is a compromise already. I think by default, security considerations should prioritize over the convenience of not flipping a switch, if needed.

On top, I observed some bug with the snap store / gnome software, as the snap permission switch states, seem to be unreliable indicators for snap connections state. All the more highlighting a need for safe defaults.

Thank you, for maintaining this snap package! <3

---

Version: zoom-client 5.3.469451.0927 System: Ubuntu 20.04 LTS, vanilla Gnome Wayland.

[drzraf]

Just found this after filling https://github.com/detrout/apparmor-det/pull/1 and let you know that Zoom attempts to list all machines's running processes (/proc//cmdline and /proc//stat)... every 10 minutes.

[detrout]

That is hard to see read what actually changed... By any chance do you remember what executables you needed to change were? It might be easier for me to just go through and add the alternate paths manually.

And yeah maybe i should ask someone who knows more about apparmor about the ptrace message. I think there's a chance it may be just looking at a child process, though I'm not sure how to express that.

[ogra1]

i don't see these denials in the snap over here, is your snapd new enough ? (newer snapd quietens all ptrace calls in apparmor IIRC) and i also think if this isn't a mis-placed comment it should go into a new issue

[detrout]

I merged in your changes by hand and added a few more access. I didn't need the dbus or gconf messages changes you needed. What desktop are you using? I'm on gnome3. I also fixed saving chat and whiteboards from within zoom.

I also could get all the warnings to go away by enabling the following, but bash, awk and unconfined ps bothers me.

diff --git a/opt.zoom.ZoomLauncher b/opt.zoom.ZoomLauncher
index d3c92fe..77b3914 100644
--- a/opt.zoom.ZoomLauncher
+++ b/opt.zoom.ZoomLauncher
@@ -42,11 +42,14 @@

   # pulse audo configuration
   signal (send) peer=/usr/bin/pacmd set=(usr2),
+  #ptrace (read) peer=unconfined,
   /usr/bin/pactl ix,
   /usr/bin/pacmd ix,

   /{,usr/}bin/cat ix,
   /{,usr/}bin/dash ix,
+  #/{,usr/}bin/bash ix,
+  #/usr/bin/gawk ix,
   /{,usr/}bin/grep ix,
   /{,usr/}bin/readlink ix,
   /{,usr/}sbin/killall5 ix,

[ogra1]

I also could get all the warnings to go away by enabling the following, but bash, awk and unconfined ps bothers me.

this is really irrelevant in snap environments where these binaries come from a readonly squashfs and their execution is completely mediated through seccomp, namespaces, cgroups and apparmor.

also ... such changes need to go into the particular interface code of snapd not the generated apparmor profiles for the snap itself... can you please file it there instead ?

[drzraf]

These last comments, while aspects are of interest for this issue (which is why I mentioned it), are intended to detrout/apparmor-det#1

[ogra1]

application specific apparmor profiles are completely ignored during snap build. the actual profiles are generated by snapd at install time of the snap based on the interfaces picked. binaries from the underlying (readonly) core snap (awk, ps etc) are essentially completely power-less.

the only influence a snap package has on the apparmor rules are by picking the pre-defined interfaces which control the apparmor snippets used at generation, if you would want such changes for the zoom snap you would have to patch snapd, not zoom, and even then things like ps wouldn't work (coming from the core snap) because they are mediated and can not just access the system information they are used to access without specific interfaces enabled and connected.

this issue is about the set of default picked/connected interfaces, direct changes to any apparmor rules are not applicable at all to the snap, they would have to happen as global changes in snapd against the respective interfaces holding the apparmor snippets. if you intend to make such changes please file them against https://github.com/snapcore/snapd.

if you want to discuss the set of default-connected interfaces (pariculary why the readonly system-observe and hardware-interfaces are connected), feel free to do so here though.

[ogra1]

@jos128 so when I disconnect hardware-observe i still get denials for zooms call to lscpu and the virtual background feature does not work anymore OOTB, nothing changed here since issue #4 ...

likewise when disabling system-observe the system journal gets massively spammed with denied pidof and ptrace calls so here nothing changed either

if zoom stops using these calls and does not degrade default functionality we can surely drop these (read only and rather harmless) interfaces, but it seems like nothing actually changed yet ...

[jos128]

@ogra1 Thanks, for looking into this. Have you observed the log spamming to continue past a certain point? As I said, I was observing just the 20 lines written for the command stated with each zoom start. However, I haven't tested all functionality and only tried on wayland.

At the moment, I can't test anything further, as the Ubuntu 20.10 upgrade broke most snap apps for me and the groovy-proposed upgrade didn't work either. or rather broke things completely, so I sadly can't help you here. (Snap issue.)

[ogra1]

that wayland issue should be fixed in the latest mutter for 20.10 already, did you update yet ? (also, the snapd fix is in the edge channel, just a "snap refresh snapd --edge" should get you the working version (you can switch back to stable once it landed in the stable channel by replacing --edge with --stable in the former command)

[jos128]

$> apt show mutter
Package: mutter
Version: 3.38.1-1ubuntu1

I think the fix is still in groovy-proposed: https://launchpad.net/ubuntu/+source/mutter/3.38.1-2ubuntu1.

However, the snap refresh snapd --edge got me the Zoom window, again. Thanks for the tip!

I try to remember checking the log, if I am gonna use it next time with a real-world session.

[detrout]

Hm. I got pulled in because I have my own apparmor profile, which is more important to me since I'm just using the .debs provided directly by Zoom and not the snap or flatpak.

I tried the flatpak but the way Zoom detected if it could do screen sharing on wayland involved reading a distro version file and the flatpak version had an unacceptable value.

[Fuseteam]

@detrout feel to open a pull request against snapd if you wish

[detrout]

You may also need pipewire for screensharing to work, in addition to getting the right values in os-releases. This is the thread about the flatpak version https://github.com/flathub/us.zoom.Zoom/issues/22

[Fuseteam]

@detrout but this is repo for the snap variant

[ogra1]

there is some discussion i'm dragged into with the zoom guys to get os-release of the snap env added to their list...not resuts to report yet though ... there is also an open issue here discussing the wayland screen sharing in issue #22

[detrout]

@detrout but this is repo for the snap variant

Yes, but you're likely to have similar problems with how Zoom tries to detect what features are available.