"Can Virtualmin limit CPU, memory, IO, number of processes, concurrent connections… per account? "
Of course. For as long as I can remember (though it hasn’t always been in there, it’s been in there for many years). At least, in Virtualmin Pro, we’ve got a Resource Limits page for limiting CPU and memory usage. I’m pretty sure GPL at least has bandwidth (Pro definitely does, but I think it’s in GPL, too). Obviously, disk quotas have been supported from the very beginning. Number of connections would be a function of number of Apache/PHP processes, so that’s mostly covered indirectly by process limits applied to the user, since all kinds of applications run under suexec, by default (it’d require a third party Apache module to limit connections specifically…if we had a Pro customer asking for that, we’d look into it, but it’s never come up to my recollection).
None of this requires CloudLinux.
“Can we achieve complete isolation between each account?”
Define “complete isolation”? Users cannot see or modify other users data or network traffic. We configure suexec, by default, and directory permissions are quite tight by default (tighter than any other control panel I looked at when we were designing our permissions model). That’s always been true in both Pro and GPL. If you can see or modify another users data in a default Virtualmin install that would be a huge security bug…and, obviously, we’d drop everything and fix it right away. I don’t know of any such bugs. With more than 100,000 active installations of Virtualmin, I think we’d hear about a bug like that.
I’ve long been opposed to chroot jails for users as a “security feature”, as it was historically merely security theater, and actually introduced pretty major potential vulnerabilities into the system (where an accident in building the chroot could result in privilege escalation, and a bug in the tool setting up the chroot would also result in a root exploit, and it was previously necessary to disable privilege escalation in OpenSSH to use a chroot shell, among other problems). But, those issues have mostly been resolved, if you are careful and make use of capabilities in the kernel and have a new-ish openssh version. So, I’ve been working on chroot support for Virtualmin 6. I still think it’s a no-op for security, but I no longer think it is a disaster waiting to happen (capabilities allow the chroot shell to not be setuid, and OpenSSH no longer needs to have priv sep disabled, so the only issue remaining is getting the build of the chroot shell app right and the risk of an administrator error leading to root privilege escalation, and we can provide tools to help protect against that).
So…yeah, Virtualmin has had pretty much everything you’re asking for, for many years. And, it’s getting chroot jails in Virtualmin 6 (because it’s finally become reasonably safe to do so a year or two back). I don’t consider chroot jails a major improvement (and they are not a security improvement, though I can see how usability and user happiness might be improved by having them feel “isolated”), but it is something that has been requested a lot over the years, almost since the beginning.
We’ve shipped a few limited and restricted shells over the years, and of course, the File Manager can be locked down (the old one could, too; that’s not a new feature in the new HTML5 file manager), and FTP can be locked down to the users home. It is only ssh that has never been chroot-able, and for what I believe are valid reasons. We’ve always advised users who are really worried about their users being able to look at the filesystem (but still being prevent from causing harm or seeing any sensitive data by filesystem permissions) and who don’t trust Linux filesystem permissions to do their job to only enable FTP and file manager access for the users they don’t trust (but, we also think that’s an unnecessary fear). The reasons we’ve said no to chroot jails for all these years is because they were a bad idea; technically they’re easy to implement (hell, I’m the one building it; if it were hard, Jamie would do it). chroot jails for users are still not a great idea, but they’re no longer a bad idea, so we’re adding support for them (I’ve asked for help testing my jailkit package for CentOS over in the developers forum, but so far no one has taken me up on it).
We’ve also go some other (real) security features coming soon. Since I feel guilty about shipping chroot jails (and the inevitable assumption that many people will have that enabling them provides some remarkable improvement in security), I want to make some real strides forward on security, as well. Ilia recently added SELinux attribute handling to the file manager, for example, which will ship with Virtualmin 6. We’ll likely have a beta SELinux policy package for CentOS systems by the time Virtualmin 6 comes out, or, if not, it’ll come soon after.
