Privilege escalation through mail manager role

[subven]

If you give someone on your Cloudron the role to manage users and mail accounts, he is not able to change user settings for admins or superadmin. Through the "Email configuration" however he is able to take over the internal mail accounts associated to admins/superadmin and if they configured their Cloudron managed email account as password recovery mail address, we have a privilege escalation.

In order to prevent this, "Mail manager" should not be able to configure mail accounts owned by admins/superadmin.

Also, pretty good advice is not to assign any of your Cloudron-managed email addresses as recovery emails.

I "fixed" this problem by not giving anyone else the right to manage mails since they potentially could take over any account on the Cloudron.

[girish]

The password recovery mail should be an address not hosted on Cloudron - https://docs.cloudron.io/profile/#password-recovery-email . But of course, this is not really enforced.

I think this is a valid concern though. So, a mail manager can add mailboxes which are assigned to an admin but then cannot edit it anymore. If he/she makes a mistake, they cannot correct it. Thinking if there is something else we can do...

[subven]

While this might be an edge case, it is something the majority of admins is not aware of.

@girish the problem with the recovery mail is that it is optional and defaults, if not set, to the users primary mail address. It is also unlikely that unpersonalized system accounts (like administrators) have private (recovery) mail addresses outside of Cloudron assigned.

I also was thinking about this "managed" Cloudron instances where you are an superadmin and give control over Cloudron to another party.

Edit: About the "what can we do": The mail manager role should not be able to edit admin/superadmin accounts and assigned mailboxes in general. It's not of their business ^^ There should also be an protection so that this mailboxes are not deleted and recreated by an mail manager.

[girish]

@subven The mailbox can also be assigned to a group. Then, we have to check if a group has atleast one user that has admin/superadmin role. Of course, one can debate why a group is set as a password recovery email in the first place.

I like your idea of protected mailboxes though. That idea is clearer. As in, have a explicit checkbox per mailbox to indicate cannot be edited by others. Have to sleep over it

[jdaviescoates]

@girish would be nice to be able to limit by domain too.

I'm incubating various groups on our server. I'd like them to be able to manage their own mail boxes, but I can't do that safely as then they can manage everyone's email on all domains.

[girish]

OK, sleeping over this... I realized, we have this issue even without mail manager role. i.e an admin can become superadmin since they can control cloudron owned mailboxes.

I think what we will do is to not send password reset to cloudron owned mailboxes. After all, they cannot access the password reset mail without the password anyway. That will prevent all the combinations atleast.

[subven]

@girish you assume that these accounts also own the specified recovery mail address which is not necessarily true. However, not sending out password reset mails to Cloudron addresses would be okay I guess. In order to fix this, you need to do two things. Implement a check where the form returns an error if the recovery mail you are trying to save ends with an domain listed in Cloudron. To fix current setups you need to extend the recovery mail sending script by the same check. This way it is pretty clear to the user what's going on and you don't need to alter current setups.

@jdaviescoates this is something I struggle with too. There should not just limits by domain but also by group. In Nextcloud you have a model where you can assign someone as a group admin and therefore he is limited to give someone permissions within the group not able to elevate himself. It's another topic because right now it's all or nothing.

[nebulon]

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.