RE: [TUTORIAL] Basic Computer Security [5]
Citrix Xen is designed as a bare metal hypervisor with clustering support via resource pools. Everything is compartmentalised into domains, dom0 is domain 0, or host domain, the privileged domain dom0 has direct hardware and kernel access, it initialises first and loads/manages domU, the unprivileged domains (VMs). Dom0 arbitrates access to resources such as hardware or network on behalf of domU.
This abstraction can provide security, but shared resource, hardware pass-through or direct access is possible for domU, it depends on how you set it up. It is possible to have a malware-test VM that shares networks and physical NICs with your host, not very secure at all. Just educate yourself about how to isolate VMs & networks, or else you'll get something nasty from a VM cross over to dom0 or out via network and back in through NIC onto all the computers in your home or office network computers.
If you want to game on a Windoze VM in domU then you'll probably need to pass through the physical GPU from dom0 to a specific domU or else Windoze & the game will not detect any compatible 3D acceleration GPU support and fail to init. Generally, templates provide a a high ubiquity/compatibility based software graphics device that is well supported.
It is definitely possible to install packages to dom0 via command line, either on console or via SSH, I've had to install zip & unip YUM packages for later versions of XenServer 7 in recent months as it no longer seems to ship with them and that's a PITA for installing updates as they're supplied as *.zip archives.
Wow looks like you are expert on this, while I am just a mere novice.
Well I have tried Qubes and so far it's decent, I would certainly not run any Windows on it and I am conservative about installing stuff as well, but I really need to learn more about configuring networks I am not good on that, so perhaps you are right about those shared resources.
But I thought some of that function is isolated by the CPU isn't it? I mean you have stuff like this:
Doesn't the hardware acceleration provide some framework to isolate guest domain's resources from the main domain?
I work with Xen everyday and manage headless (no GUI) Linux servers from command line, just wanted to share some knowledge. I've seen Qubes, was very interested and would like to experiment, but, time....
dom0 isolates domU from direct hardware access by abstraction, the real hardware isn't presented to the VM, only a software device representing it is, the guest OS has direct access to this virtual device as if it were real, anything this device does/needs is then carried out by dom0 on the real hardware.
HW>hyper>VM>guest OS + DLLA network or networking device can be shared with host & other VMs or it can be private to a specific VM, depending on how it is defined. It's possible to make a network shared between VMs that never leaves the hypervisor or goes out through the physical NIC at all, just passed back and forth between VMs. At any rate, all VM network traffic that traverses the NIC and local network can interact with other hosts on that network.
The isolation of VM private data & working sets is a big and complicated topic, as is network isolation, but the primary concern is the belief that virtualisation has an innate inoculating effect on threats. Consider this:
VM runs in complete isolation. VM has virtual NIC and traffic from VM traverses physical NIC into local network. VM is compromised, let's assume malware. Malware is network aware/capable, let's assume it's a cryptolocker rasomware. After compromising the VM malware will next attack all hosts on local network, including the hypervisor host.
Whether or not the NIC is virtualised or not it still has access to the local network and functions more or less the same as a physical NIC, if it couldn't there'd be no purpose in a virtual NIC. To isolate the traffic would require a second physical NIC in the host system connected to an interface on your networking equipment specifically configured to put this traffic in a separate network, the most common method being a VLAN but some enterprise switches/routers allow for port-specific mapping that allows for strict isolation. Example of NIC2 VLAN:
VLAN100 (default)- switch/router ifaces 1-8VLAN666 (user config)- switch/router iface 9NIC1>CAT6 cable?iface1NIC2>CAT6 cable>iface9This is of course grossly oversimplified for illustration purposes, but assume that VLAN100 is 192.168.1.0/24 with DHCP and all hosts, physical or VM, that connect to it, virtually of physically on interfaces 1-8 of your network equipment, get an address in that range and can chatter away with each other in their happy little world. Meanwhile, Mr Test Gimp™, a salubrious VM of questionable intent, has a dedicated phys NIC passed through hypervisor to it, it's phys conx is to iface 9, and is on LAN 10.1.1.66 with router providing gateway/routing/NAT to internet. Isolated, yet accessible via hypervisor conole (GUI or otherwise), as if it was a box with it's own internet conx.
VM or otherwise, a box is a box is a box, connect them all together in a LAN and infect one, you've risked them all.
It just needs to be kept in mind. Same philosophy as your advice on antivirus not equal to immunity a-la false sense of security equals increased risky behaviour.
I'm glad you take time to share advice and tips on safe computing practices/behaviours with others. I'd write a lot of the same myself, have written some, would write a lot more, but, time...
The ultimate problem with antiviruses is simple. Any clever virus would infect the antivirus first, since the antivirus has total (invasive) control over the PC (not to mention privacy concerns).
Once the virus has infected the antivirus it can do the harm without being detected and the user having a false sense of security afterwards.
It's better to face the threat naked and be prepared for the potential malware by changing the user's behavior (verify software, not clicking random links, not opening attachments ,etc..) into a more responsible computing instead of relying on snake oil software to protect them.