Usually people say directly using root account is a very bad idea. However, my current setting is like this: to achieve a higher level of isolation, all services have their own virtual machine instances.

In this scenario, is it okay to simply use root account on every virtual machine instance? The common argument is that separating root/non-privileged users reduce the attack vector--even if one service is compromised, other services on the same system can still be secure if they use their separate non-privileged accounts. But since there is only one service for each system, this argument seems invalid.

I am aware that there are some other arguments. For example, rm -rf, etc could be less dangerous in non-privileged accounts. But I think this is not a huge concern since those services are not updated very frequently and the virtual machine instance will be backed up regularly.

  • @mentallurg emmm...I would say no... what I expect are some technical answers for sysadmin...
    – Mamsds
    May 25 at 5:13

I would agree that root can be used on your VMs much more relaxed due to the compensating controls that you specified however without knowing your setup and if this is a corporate or personal set.

My considerations as to why root on all is a bad idea:

  • As an attacker, automatic root account would allow me easier access to misuse the VM and put my own tools on.
  • If access to the server is automatic root, logs can easily be deleted/modified/read. This could include any bash history.

Virtual Machines are also commonly given a misconception around how secure they really are. For a good resource from another Infosec Stack Exchange comment just look here.

At the end of the day this is your environment and this is your risk acceptance. If the value of keeping them root out of ease is best for you I would say that is fair (judging by you being on this forum and knowledge of the dreaded rm -rf I would say you are already capable of weighing the risk adequately).

My summary would be:

  • If it was my home network, non-important, and weren't externally accessible outside my LAN, I would rely on my network logging and monitoring and throw access out the window.
  • If this was any other situation (running accessible services, corporate use, R&D, sensitive PII, etc.) I would DEFINITELY enable least protection privileges and check those SUID bits and GTFOBins.

Hope this helps.

  • Thanks @Rivesticles. Regarding what you said, I have a follow-up question: My current understanding is that while jail breaking/rooting is pretty difficult, it is way easier than escaping from a virtual machine (currently I am using KVM but I think vmware, virtualbox, kvm, etc should be more or less as secure as each other). Is this perception generally true?
    – Mamsds
    May 24 at 5:13
  • @Mamsds that current understanding (as far as I know too) is true. For the most part with the right firmware and community jail breaking/rooting things (lets say phones) is achievable and in some cases a given (Google Nexus), where as escaping a VM is more of an exploit which shouldn't usually happen with good patching and config. Most virtualisation platforms are similar to each other, there might be differences however the core thing that will get you is not vendor selection (unless you pick something obscure) but not hardening, monitoring, and patching/updates. May 24 at 5:30
  • another thing I am thinking is, suppose my host machine is solely used to host VMs, do you think using non-privileged account adds any extra benefits? My thought is like this: let's say I use a non-privileged user to manage all VMs, if such non-root user is compromised, all VMs are compromised, protecting host OS's integrity is meaningless since it is only used to host VMs. As a consequence, using root/non-root to manage VMs will be almost the same since all that important is VMs and using root/non-root won't make VMs more secure.
    – Mamsds
    May 24 at 5:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.