Cloudron 5.2 released
-
We released Cloudron 5.2 for all now. See the blog for screenshots and more info.
- Features
- Members only mailing list
- Inter-domain aliases
- Redis status
- Backup retention policy
- Enhancements
- Backup config downloadable (and uploadable) as JSON
- OVH Storage Backend
- App graphs - currently, only memory graphs. CPU graphs/Network graphs coming soon.
- Box Backup listing
- New base image cloudron/base:2.0.0. All apps and addons have been updated to use this image.
- Security
- EC Certs for all the apps and email
- Improved sandboxing - apps cannot sniff traffic anymore. Thanks @will
- Backup encryption - our current implementation was not secure. Thanks to @mehdi for helping us implement this properly. Unfortunately, the new encrypted backups are not compatible with older encrypted backups. So, if you try to restore to a backup which uses the old format, Cloudron will warn you as such. If you want help to import/restore from such backups, please contact support@cloudron.io.
- Misc
- Changes to Update Strategy. You can now click 'check for updates' button to always get an update. Don't have to ping us to whitelist your installation to get the latest update. This comes with risks, of course, since you are not part of our careful rollout cycle. In the future release, we will add a warning about this (but let's see if it's a real issue in practice)
- Stopped apps. Stopping an app will now also stop dependent services like redis. This change in behavior means that Cloudron cannot take a backup of a stopped app because the backup code relies on all services to be running. Instead, the code will simply re-use the last known good backup of the stopped app. For this reason, it is recommended to trigger a backup before stopping the app.
Other notable changes
- Fix bug in disk usage sorting
- Mail: allow an external MX to be set
- Ensure stopped apps are getting backed up
- Spam: large emails were not scanned
- Graphs: fix issue where large number of apps would crash the box code
- Add new wasabi s3 storage region us-east-2
- mail: Fix bug where SRS translation was done on the main domain instead of mailing list domain
- Features
-
Hi @girish - Great work as always!
Just one thing though... there seems to be some contradiction or something needing more clarification anyways regarding stopped apps and backups for those stopped apps.
Under your Misc heading for stopped apps, you say "Cloudron cannot take a backup of a stopped app because the backup code relies on all services to be running" but then later under Other Notable Changes you say "Ensure stopped apps are getting backed up" which contradicts the earlier statement.
I am presuming that the Misc one though was specific to any apps using redis for example, such as the Unmanaged Wordpress app? If so, this may explain why my stopped apps still aren't backing up, as it's an Unmanaged Wordpress app that even though I've removed the redis plugin from it it's still trying to take advantage of it because of the way that app is packaged (I still think on another note that redis shouldn't be part of the package, not everyone needs that), and my forum post on that stopped app backup problem is here which I coincidentally updated the other day: https://forum.cloudron.io/topic/2392/stopped-apps-not-getting-backed-up-is-this-intentional/11
-
@girish said in Cloudron 5.2 released:
Improved sandboxing - apps cannot sniff traffic anymore. Thanks @will
After seeing this and reading this article from RedHat about capacities and containers
I pushed the idea further and test.
Also when I saw then docker-compose of Searx drop all capacities by default and add only few I felt something was weird with the insecurity of docker era.than I start to play with my precious docker-compose.yml of 300 lines.
Like we could see in docker-compose of searx, but it still surprise me, almost all containers could run with only 3 capacitiescap_drop: - ALL cap_add: - CHOWN - SETGID - SETUIDMight worth to dig in this direction
-
also a significant argument of why people should pay 15$ per month
since then I go around the net look at all these Docker-Compose and Dockerfile Project and I'm scared.
No wonder why the internet is broken and the data leak from everywhereAlso, for now, only here my thought found echo that give me a lot of hope.
@girish how could I (we) review and test this in a way Cloudron team would consider our effort ? -
@JOduMonT I opened https://git.cloudron.io/cloudron/box/-/issues/694 to track this. Will schedule it for the release after 5.3.
-
@girish nice, from what I understand it could be done easily and dropping everything than watching error at the runtime.
such as mariadb seems to not complain with these setting
mariadb: cap_drop: - ALL cap_add: - CHOWN - SETGID - SETUIDon another hand everything with PHP seems harder to limit.
-
@JOduMonT said in Cloudron 5.2 released:
cap_drop:
It looks like it is:
Let's look at the default list of capabilities available to privileged processes in a docker container:
chown, dac_override, fowner, fsetid, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, audit_write, setfcapBottom Line
You are probably running containers with a lot more privileges than they need. Dropping these capabilities when the containers are in production would be a great idea.Reference:
https://www.redhat.com/en/blog/secure-your-containers-one-weird-trickFrom Stack Overflow:
Ok, what you can do is run your container and use pscap and filecap to see what capabilities your container needs. Use captest to test them out. Then, remove all capabilities except what you need with --cap-drop ALL --cap-add foo. Check here for more info github.com/docker/labs/tree/master/security/capabilities. Let me know how that goes for you. -
for what it worth, in my /etc/docker/daemon.json I always define.
{ "no-new-privileges": false }which from what I understand prevent container processes to gain additional privileges after their start.
ref:
