chroot is not a security feature, despite the widespread belief that it is. It basically just hides some filesystem details from the logged in user. And, in fact, a chroot jail can open serious security holes if you don’t understand the implications of putting things into the jail. Though, most of the security risks of chroot jails have been resolved by use of capabilities in the Jailkit packages we provide, I am not entirely confident there aren’t still ways to shoot yourself in the foot. chroot has such a long history of exploitable usage that I am hesitant to say anything nice about it (we added it only after capabilities became universally available across all supported distros and in Jailkit).
I’m not sure. I’d have to test, which I can’t do at the moment.
No. Let’s Encrypt is not run within the chroot.
I would substitute “abilities” with “limitations”. But, yes, the user is chrooted, not the domain. Sub-servers have the same user as the parent, thus they have the same chroot.
Yes, you can turn this option on/off using virtual-server.name - Administration Options ⇾ Edit Owner Limits: Server Owner Limits / Other restrictions page after virtual server was created.
Appreciate the feedback guys. I basically plan to use Vmin / Webmin from now until infinity, warts and all So my current goal is to design the most secure base image / snapshot installation of Vmin that I can and then use that image to install all my future server… hence the security focus. (among other reasons)
I have some limited experience with jailkits…
I thought the primary benefit of jailkits was/is that you can prevent malicious actors from gaining sudo privileges, by only adding apps needed to run websites and nothing else into the jailkit.
So, I guess my question is…
How does using a normal Virtual Server, per user, prevent a malicious actor from hacking a random user’s Virtual Server and somehow gain access to the core server itself?
Or is the only way to truly achieve that level of security is by chrooting the Virtual Server?
Or is the only way to truly achieve that level of security is by chrooting the Virtual Server?
Jailkit doesn’t give you any extra security in this regard, and security via obscurity is not really considered. Besides, Jailkit is an additional complexity. There is no need in enabling it to make your server more secure. For instance, I am not using it.
How does using a normal Virtual Server, per user, prevent a malicious actor from hacking a random user’s Virtual Server and somehow gain access to the core server itself?
At first, simply make sure that you use standard Virtualmin installation, i.e. install it on a clean state instance, using official install.sh script and that installation goes well (all installation steps are completed successfully). Later, make sure that you use strong passwords for your virtual servers, as well as strong passwords for SSH/Webmin/Virtualmin/Usermin logins. Try using key authentication for SSH and disable plain password authentication (at least for root user). Also, enable two-factor authentication for Webmin/VIrtualmin/Usermin logins. Login failure daemons, like fail2ban will also make it more difficult to brute force your passwords. This is mainly it.
Now, in terms of inter-user security — if you want to isolate users from one another, simply always create a parent virtual server, which will setup a separate Unix user, as separate Unix user is the main layer of security that just works naturally. If an app (e.g. like WordPress plugin) that runs on one virtual server is hacked, the attacker will not be able to access files under different virtual servers as they are owned by a different user, as PHP scripts are executed as given virtual server owner. Although, the hacker would most probably be able to get a list of /home directory (that would depend on PHP configuration though), i.e. see the names of other virtual servers hosted, so if you want to prevent this from happening you would have to use chroot setup.
Default Virtualmin installation is very secure by default. Try not to deviate from configuration of what standard installation provides, unless you know exactly what you’re doing. And remember, extra complexity almost always highers the risks of bringing in more potential issues to the field.
So as long as the parent virtual server linux user doesn’t have sudo privileges, then if that user is hacked it fundamentally won’t matter because the user can’t gain elevated privileges to do damage.
So as a strategy…always login to my Virtual Server as root… giving it only email services (no website, no ssl, (i.e minimize attack vectors), meanwhile removing all other users from sudo should be the safest way to manage Virtual servers…
Hacked in which way? If it’s a bug in PHP code and an attacker can execute some random commands? Well, in this case even if the account is in sudo, it won’t be a problem. However, if an attacker guesses the password for the user (by brute forcing, using flawed PHP app) and this user is in sudo then it’s a major escalation issue.
So as a strategy…always login to my Virtual Server as root… giving it only email services (no website, no ssl, (i.e minimize attack vectors), meanwhile removing all other users from sudo should be the safest way to manage Virtual servers…
Virtual server domain owners shouldn’t be really able to use sudo. Most of the time it is never necessary. However, again, if the password of a user in wheel group is strong it won’t be a major problem. Meaning, if PHP app is hacked, you wouldn’t bother about escalation privileges, as it wouldn’t be possible to brute force a strong password fast enough and without being noticed.
Also, make sure that you’re installing latest system packages upgrades, as just recently there was a serious bug fixed on sudo side.
We are speaking the same language… simplified: never have a forward facing virtual server user (i.e a virtual server with attack vectors like cms, php apps, etc) with sudo privileges. Stated differently… any parent virtual server user that is forward facing, remove from sudo and things should be pretty safe.
That doesn’t really logically follow. Logging into Virtualmin as a domain owner user is as safe and secure as you make it. By default, those users are quite limited in what they can do (and thus, safe). Be very careful granting them access to Webmin modules that aren’t a usual part of Virtualmin, though, as Webmin is an administrative tool with root access. Webmin modules can basically act as sudo for Virtualmin users.
But, yes, virtual server owners should not have sudo, or if you need a virtual server owner to have sudo, limit it to the exact command(s) they need to run (but I am having a really hard time coming up with a good reason for a domain owner user to ever need sudo).
So my current goal is to design the most secure base image / snapshot installation of Vmin that I can and then use that image to install all my future server… hence the security focus. (among other reasons)