On a technical note, docker is accessed by apps via proxy. This proxy verifies that only apps that request the docker addon can access the docker API. The proxy also ensures that random volumes cannot be mounted (only /app/data of the app can be volume mounted).

• Write to support@cloudron.io
• Alternately, you can open a "confidential" issue in https://git.cloudron.io/cloudron/box/issues (this does require you to register in our gitlab and enable 2FA).

(But it's indeed good that is was noticed and changed)

@girish thanks for the quick update! L

Thinking on it a bit more, for more defense in depth I’m realizing that if the server is running as yellowtent the directory ought to be read only for that user. Otherwise a remote execution vulnerability is enough to own the server and escalate privileges.

I’m not a proper security auditor though...

Have you considered getting a professional audit?

I was just reading the documentation on how to do user impersonation and it appears that you only need access to write to /tmp. This is something that any non-privileged Unix user can write to.

/tmp is only writable when in CLI or an app that has a feature to write to this (in the docker container, not the cloudron server)

Thanks for reporting!

The process I laid out will allow one to get system root access.

It puts a Cloudron server one arbitrary code execution bug away from a fully pwned system. Even an admin running a non-privileged script will allow someone to gain access to the entire server.

This will be very easy to mitigate. I believe the easiest way is rather than using/tmp, which is world writable, put the files in a directory that is owned by the cloudron user. Users can write to it by doing echo '{"blah": "blah"}' | sudo -u cloudron tee /var/cloudron/ghost.json, then have Cloudron delete the file afterwards.

The issue is that any unix user can gain access to admin through impersonation by writing to /tmp. Then they are free to install anything they want, ignoring any warnings and use that to escalate to unix root.

True but we have not designed Cloudron to be safe from users with SSH/terminal access. For example, the database itself is available to all users. Our idea has always been that only the Cloudron admin has SSH access. In fact, with Cloudron 5, we are making this distinction a bit more clearer. The first admin is now called an 'owner'. Owner is someone who has access to server / administers the server / installed the Cloudron. Owner can add one or more admins who install apps and manage users. Admins don't require or need ssh access.

Also, managing impersonation in app would do away with this as well.

So, I think the attack vector here is that an unknowing admin installs a custom app with the docker addon. Maybe, we need to add security warning in https://cloudron.io/documentation/custom-apps/addons/#docker for admins ? We could make it the docker addon unavailable for custom apps altogether. Not sure if this breaks "hackability"/tinkering