Cloudron Forum

This is fixed for next release with https://git.cloudron.io/cloudron/box/-/commit/3477cf474f32a51c62aef65015e615db62bca4f7 For the other feature request about domains, please make a separate thread there, but I can already say that Cloudron is still designed to work for a setup of one Cloudron per organization and not many maintaining isolated organizations on one Cloudron. This will add all kinds of complexities for the 99% use-cases Cloudron is currently used for.

@girish It sure did. I thought it was a simple matter of brute forcing 16 characters. I’m glad that’s not the case. Thanks for the clarification!

@nebulon thanks! I'm not getting my hopes up too far, but hopefully this will somehow also resolve all the issues that loads of the official plugins have when trying to install them on Cloudron...

Maybe @mehdi has some ideas here since he wrote the initial app. If I understand correctly, you are trying to put the OpenVPN certs into openwrt and this somehow leaks DNS. How are you testing this?

This is fixed in https://git.cloudron.io/cloudron/dashboard/-/commit/b3cdcb2adb4666f274ed23f2ab05428563531dc8

Yes, as far as I understand each Nextcloud would initiate a document edit session with its own document URL and token exchange, so those should be isolated from one another.

@LoudLemur I have seen this idea implemented on some services now. I guess this will only work for the Cloudron dashboard?

Thanks for the info, but we do not use this module, so we are all good.

Indeed, we use that angular version 1.5.8 and can look into updating that. Generally though I am not sure how one would exploit this in the Cloudron use-case. So I don't think it makes much difference. The only user-content which is dynamic in that sense would be the footer, but if the admin sets a malicious footer, I guess the situation is already an issue.

@potemkin_ai thanks for reporting. It seems nfs-common depends on rpcbind which starts the service at port 111. rpcbind is only needed for NFSv3 . I have disabled rpcbind in the next release (8.0.1) . Cloudron only supports NFSv4 out of the box.

@nj Cloudro relies on Ubuntu LTS versions and security updates are enabled automatically (independent from Cloudron releases). So once the ubuntu securty team updates the kernels, all Cloudrons will get is as well. Since this is a kernel issue, you will likely see some "reboot required" notification in your Cloudron dashboard afterwards.

@girish I would say pick and choose what is applicable obviously you would know best it's also worth noting there are CIS benchmarks specifically for Docker Containers which might be a better fit. You could combine the two for better hardening. https://www.cisecurity.org/benchmark/docker/ https://github.com/docker/docker-bench-security Let me know what you think

@mastadamus thanks so much for investigating. I have removed it for next release (7.1) - https://git.cloudron.io/cloudron/box/-/commit/6492c9b71f80120413ff4ae7eefa2f03dc96ea0f

Both the old java as well as the bedrock edition have now been updated.

@girish ah i didnt even notice bevause of all the 4j notices my eyes where too open thx for looking at this anyway

@jodumont I recently posted about crowdsec under feature requests. I think crowdsec is more appropriate, afaik, for cloudron

@fbartels I do believe you.

The backdoor was removed before it was compiled into a binary for admins to download so there is no issue for anyone running PHP. However this does prove to be an issues in regards to PHP's safety - They have moved to GitHub (@girish mentions in his reply) and will be better closely monitoring pushes and merges into the code base. PHP's Own Nikita Popov: "The changes were on the development branch for PHP 8.1, which is due to release at the end of the year" which means the code has not been distributed. It's a big deal but not as big as everyone is making it out to be. Hopefully this does NOT happen again.

Ubuntu notice - https://ubuntu.com/security/notices/USN-4891-1