Why I'm not using ONLYOFFICE yet.

I'm a huge fan of Nextcloud and version 18 brought great integration with ONLYOFFICE. I'm not using it though because it ships with binaries that aren't always straightforward to execute.

My last post on Nextcloud & Apparmor explained how to get a quick profile going. It ended with a far from perfect profile as an example which prevented the POC's of CVE-2019-11043 from working and likely hampers other attacks, even if not perfect.

The general approach of the policy...

  1. Allows reading & writing /media/nextcloud - the actual data.
  2. Allows reading /var/www/nextcloud so that php can execute the code within.
  3. Disallows pretty much everything else, including:
    • executing random things like shells into doing weird things
    • changing code that php interprets (bullet 2)

Unfortunately, the onlyoffice extension is one of few which relies on shelling out... as part of the build process, a copy of the upstream onlyoffice docker container is extracted which includes at least one binary, x2t used during normal operation.

This is annoying for many reasons, not just breaking my dumb apparmor profile. It means the application isn't portable, failing on non-linux e.g. freebsd and in other docker setups.

For me, it's not just a matter of granting an allow x policy on the binary in question, even if I trusted it.

There doesn't seem to be a simple way for a PHP application to run a binary directly, it must shell out which means bash or dash via proc_open - whitelisting of which would open up a much larger attack surface?

OnlyOffice looks like the way forward, it's not marked as demo software and doesn't come with restrictions while being a first class NextCloud application (minus that embedded binary) I suspect the problem will be solved shortly..