Required webmin user rights to act as BIND cluster slave


For security reasons, I'd like to create and use a dedicated webmin user account for the BIND Cluster Slave function. Is it correct that I can add the same Webmin remote server multiple times to a Webmin, with differing credentials?

What rights does a Webmin user account need to be used in BIND Cluster Slave?



I can't guarantee that adding the same system multiple times would work, if they all have the same hostname. What would work is adding them with different hostnames that resolve to the same IP though.

For the webmin user to be usable in this case, they need to have permissions to accept RPC calls. This can be set at Webmin Users -> username -> Permissions for all modules -> Can accept RPC calls.

I wouldn't rely on this as a way of restricting what a user can do for security purposes though, as the RPC permission applies to all functions in all modules.

This means that when a user is allowed to receive RPC calls, it so to speak has "remotely called root rights"?

Hmmm. What would you suggest doing security-wise in this case? I really would like not to enter root credentials for one Webmin into another one, after I already suffered from an unfortunate hacker attack, where Webmin credentials entered in a vulnerable web software (not Webmin) enabled the attacker to gain root access to Virtualmin.

ronald's picture
Submitted by ronald on Fri, 02/24/2012 - 11:20 Pro Licensee

Wut? Can a hacker gain root access to virtualmin using some web software? What was this software precisely and how did (s)he gain access?
Safe we must be :)

Right now, with Webmin's current RPC security architecture there isn't any way to create a "limited" RPC account.

However, you could make it hard for an attacker by creating a Webmin user who has access to no modules, but can receive RPC calls. Even if an attacker captures that password, he wouldn't be able to login to the remote Webmin in a browser - we would need to code up a script that uses the custom RPC protocol I created to access the remote system.

Well, as I indicated, that web software was not Webmin. Nor was Virtualmin attacked directly. It was a customer management software (WHMCS), running on a separate machine, which had a serious security issue (PHP injection due to flawed parameter checking). (For some reason, the developer's email informing about security update did not reach me - they claim their email server was okay, but still their customer mass mails didn't get to me. In contrast to the monthly billing emails. Go figure.)

The attacker was able to execute arbitrary PHP code. Thus they could read the WHMCS config file which contained the database password, and in that database the Virtualmin root password was stored, as to make use of WHMCS' Virtualmin integration module which allows it to auto-create domains using RPC calls.

To prevent stuff like this from happening again, I'd like to avoid storing (root) login information to one system on another as far as possible. This includes me not using WHMCS' integration stuff anymore, and I'd also like to avoid entering root information for the BIND Cluster Slave thing.

I'd prefer to have a Webmin user that is allowed to create/delete BIND zones, and only BIND zones, and nothing else. No matter if logging in locally or used through RPC calls. This way, if one Virtualmin machine gets compromised, the attacker at least cannot spread to my other ones through stored login credentials.

I'd prefer to have a Webmin user that is allowed to create/delete BIND zones, and only BIND zones, and nothing else.

Unfortunately, right now there is no way to do this ..

Alright, you might want to put it on your todo list, seeing how entering root credentials for another system could constitute a security issue.

Certainly, during the roughly 1.5 years of me using Virtualmin, and using the BIND Cluster Slave feature, no security flaw occurred due to those credentials. But as the recent events I depicted show... better safe than sorry!

Its not trivial, as the rpc feature allows access to very low level API calls in webmin, which run with root permissions.

The only fix would be to move the slave DNS functionality to a higher API level, but no such level exists yet.

Yes, I can sure see how this wouldn't be trivial.

The slave DNS thing is, in this regard, only an example too. It'd be best if, when a user is allowed to accept RPC calls, the things that are to be executed through RPC are validated against the user's other access rights. They can be executed with root rights, but e.g. a remote "create zone" call should only be accepted if the user has the RPC and the "manage zone" rights.

ronald's picture
Submitted by ronald on Sun, 02/26/2012 - 10:51 Pro Licensee

I actually had this going too with whmcs. Someone created a domain without permission and also bought a domain (which I got refunded)
I now upgraded to version 5 which was long due...

edit: oh and I don't use root for this but a special user who can only create domains and nothing else..