ogra1 / zoom-snap

75 stars 13 forks source link

Default permissions too wide? #4

Closed calderonth closed 4 years ago

calderonth commented 4 years ago

Can I ask why the following permissions are needed?

   sudo snap connect zoom-client:hardware-observe
   sudo snap connect zoom-client:network-manager
   sudo snap connect zoom-client:process-control
   sudo snap connect zoom-client:system-observe

I've removed manually some of the permission that are created and Zoom still works.

It would be good if by default only the minimal set of permissions is enabled so that people who just want to participate in VC can do so without exposing a wider attack surface (i.e. home share, network-bind, etc).

calderonth commented 4 years ago

More specifically also in the YAML file:

      - audio-record
      - camera
      - desktop
      - hardware-observe
      - home
      - network
      - network-bind
      - network-manager
      - opengl
      - process-control
      - pulseaudio
      - removable-media
      - screen-inhibit-control
      - system-observe
      - unity7
      - x11

I would highly recommend removing: network-bind, network-manager, removable-media, system-observe, home, hardware-observe. Do you have reasons for those to be there by default?

ogra1 commented 4 years ago

network-bind is a hard requirement for anything using the socket syscall, i can not drop it ...

network-manager is there because zoom can query network manager via dbus to find out if the network is up ... you can safely disconnect it indeed with only limiting comfortability but not functionallity.

removable-media is not auto-connected but like home it will allow you to store recordings to your home or usb media or import backgrounds from usb stick or your home dir for the virtual background feature... both can indeed also be safely disconnected if desired

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 ...

note that none of the higher privileged interfaces will auto-connect anyway so it is up to you to conciously allow them, to run zoom with a completely quiet log all of these interfaces are required though (except for pulseaudio but see issue #3 for this, it is needed for older installs) and thus i will not drop them ...

ogra1 commented 4 years ago

in fact ... verifying the interfaces again, the process-control plug does not seem to be needed anymore with the latest zoom binary, i will drop this one ...

calderonth commented 4 years ago

ok thanks for the initial feedback. Regarding network-bind I'm not familiar enough with how Zoom is working but generally speaking this is a permission related to binding to a local port and act as a network service (for instance an HTTP server). Network clients would not normally require this, is it the case here because of the architecture of Zoom where it's expected to attach itself to a local/randomized port?

ogra1 commented 4 years ago

the communication to the zoom server is bi-directional so you need the socket and the listen syscalls, network-bind is the one interface that provides them ... in your journal or dmesg output you will see something like:

[75614.818711] audit: type=1326 audit(1585918663.533:34636): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=13317 comm="zoom" exe="/snap/zoom-client/47/zoom/zoom" sig=0 arch=c000003e syscall=50 compat=0 ip=0x7fa296ef49d7 code=0x50000

if you run with it disconnected ... syscall 50 translates to "listen":

~$ snappy-debug.scmp-sys-resolver 50
listen
~$

you will notice that even snaps like chromium (have to) use network-bind despite not being a server of any kind ...

calderonth commented 4 years ago

OK thanks for your input, I'll keep digging on my end :-)