App_api should be marked as "insecure" until an isolated deployment model is supported

[ohthehugemanatee]

The Docker Deploy Daemon recommended configuration (AppAPI Docker Socket Proxy or AIO Docker Socket Proxy container) breaks Docker container isolation and Nextcloud/webserver user isolation. The first described configuration in the doco doesn't offer even that security, and there are no checks to warn the user. It is a significant security risk which users should take consciously - it is not appropriate as an out of the box feature with no warnings.

The docker socket proxy containers are thoughtfully built and much better than nothing! But still, they open a significant attack surface. Access to the nextcloud database (haproxy password) grants the ability to deploy arbitrary containers, limited only by naming pattern and number of volumes. This is effective root access on the Docker host. Docker documentation strongly advises against this pattern as a security risk.

Attaching a docker socket to a web service is a significant security risk which home users are likely to take unknowingly, and enterprise users do not expect in a "stable" "enterprise" product which includes large organizations and at-risk groups as primary users/customers. Amnesty International is a case study on the website, after all! There is fantastic promise in app_api, but if image preview providers are considered too insecure to enable by default (according to the threat model page), the docker socket proxy - and app_api by extension since that's the only supported option - certainly should be considered insecure, too.

I don't mean to be a hater; if it's really a requirement to allow Nextcloud Apps to launch their own containers there are plenty of ways to make this work. Top of my head:

• make the remote docker host the recommended approach, because it is isolated from the NC host and therefore has more limited issues with escalated data and resource access. Plus it is easy to state the risks in an error message.
• Recommend sysbox (and use it in the AIO VM image). (This would also support kubernetes)
• Instead of recommending the user manage a container that proxies the host's docker socket, recommend they manage:
  • a docker-in-docker container. This second container has to be run privileged - good, the user has to opt-in to the risk - and it can contain all the child containers without breaking isolation.
  • a firecracker-in-docker container, which starts a microVM with an isolated docker daemon. This would isolate the ExApps containers.
  • each ExApp container manually, and smooth the Ux to do that.
    • Eg App_Api admin pane could list ExApps that don't appear to be running, and the appropriate docker run command for each one (including auth tokens)

I am sure the team has or is considering these kinds of approaches. But until a better security model exists than a Haproxy password and some regexes, this app should be marked as insecure and not enabled by default.

[DaphneMuller]

hi, we have seen your report and are discussing it within the team. A longer reply will follow :)

[oleksandr-nc]

Thank you for raising these important questions, Campbell. I'll try to address each of your points:

Image Preview Providers and Safety

but if image preview providers are considered too insecure to enable by default (according to the threat model page), the docker socket proxy-and app_api by extension since that's the only supported option - certainly should be considered insecure, too.

Our stance is that if the malicious code is not running in PHP, then the inherent risks are different. Image preview providers are not deemed entirely safe because, in theory, they can be exploited to allow code injection into a web user's environment. However, when they are disabled and no malicious code is present in the web context, what specific risk do you see emerging from this setup?

---

Docker Socket Proxy and Attack Surface

The docker socket proxy containers are thoughtfully built and much better than nothing! But still, they open a significant attack surface. Access to the Nextcloud database (haproxy password) grants the ability to deploy arbitrary containers, limited only by naming pattern and number of volumes. This is effective root access on the Docker host.

The Docker Socket Proxy (DSP) is designed to prohibit container creation unless the “HostConfig.Privileged” flag is explicitly set. You can review the configuration here. If you've found a scenario where this isn't enforced, please let us know through H1 so we can address it promptly.

---

Nextcloud Database and HaProxy Password

Access to the nextcloud database (haproxy password) grants the ability to deploy arbitrary containers

The HaProxy password is stored in an encrypted form - just like other sensitive values within Nextcloud - so simply reading it from the database does not enable unauthorized container deployment.

---

Marking the App as Insecure by Default

this app should be marked as insecure and not enabled by default

While the application is enabled by default, it does not automatically have Docker access - this is specific to the All-In-One (AIO) setup, where only certain containers have that access by design and AIO always use the DockerSocketProxy and not a "raw" socket. We acknowledge the concerns and are continuously considering how best to mitigate these risks.

---

Improved Security Models and Deployment Approaches

make the remote docker host the recommended approach, because it is isolated from the NC host…

This is a valuable recommendation, and we will promote the remote Docker host approach, which offers better isolation from the Nextcloud host and simplifies risk communication through clearer warning messages.

Recommend sysbox (and use it in the AIO VM image). (This would also support kubernetes)

We will definitely consider integrating sysbox in our AIO VM image - thank you for pointing this out, cc @szaimen.

Instead of recommending the user manage a container that proxies the host's docker socket, recommend they manage…

All these methods would greatly complicate the setup process and could cause significant confusion. Moreover, there is already plenty of information available on how to restrict Docker using keywords like "namespaces, cgroups, docker." However, you are right that we can improve our documentation in this direction, and we will work on it. We are always open to pull requests on this topic if anyone would like to contribute.

---

Ongoing Security Improvements

Thank you also for recognizing that the docker socket proxy containers are thoughtfully built. We are continuously working on improving both usability and security. In fact, we're in the process of developing the successor to DockerSocketProxy (HaRP), which will incorporate stronger security rules when we finish it, to further mitigate potential risks.

---

Thank you for your feedback and detailed analysis. We are pleased that the topic of security is regularly raised, as it helps us receive new ideas and continuously improve our software.