Hot answers tagged

10

Theoretically, the isolation of Docker is not quite as strong, because parts of the system are shared (kernel is shared, container has a chroot of the original filesystem, etc). However, for most purposes it's good enough. With chroot, cgroups, etc, and the ability to run containers under an unprivileged account (so root in the container is still limited on ...


4

You are looking at two different vulnerabilities. Dirty Cow is a privilege escalation in the operating system. So, if your VM is vulnerable, that means it's possible to get root privileges in the VM's operating system, not in the host system. In order to be possible to access the host, you need a vulnerability in KVM or QEMU that allows you to escape from ...


3

The answer to that depends. Is your VM connected in a host only network? or a virtual subnet that is not connected to the internet? or is the vm also allowed to access the internet (i.e. bridged or nat)? Having root access to a machine on your network with no password is a huge security risk. If it got exploited somehow, it would give an attacker carte ...


3

Paravirtualized drivers will be a security risk only if the paravirtualization interface is designed in a way to leak hypervisor state or information to the guest. it is no more secure or insecure than having system calls in an OS or having applications talking to device drivers. If you think about it, guest talking to a hypervisor is similar to an ...


2

There is no guarantee with any computational system that it can't be broken/manipulated. Here is a list of vulnerabilities in QEMU, its up to you to determine if your specific version is vulnerable or not, and how "easy" it is to be targeted. As a side note: we tend to avoid absolutisms in infosec because there usually is no guarantee of anything, what is ...


2

Looking at this github page and this RedHat page it seems that the attacker can write to /proc/self/mem and ptrace files. The ACL that will be affected is the ACL of the VM and not the host machine. This means that the files that are shared between the host machine and the VM (remember the VMWare file sharing bugs) will remain vulnerable. Apart from that, I ...


2

Q: .. do the host as well as the guest need to have Meltdown/Spectre mitigation enabled? Yes When these vulnerabilities announced, QEMU posted on "QEMU and the Spectre and Meltdown attacks": Right now, there are no public patches to KVM that expose the new CPUID bits and MSRs to the virtual machines, therefore there is no urgent need to update QEMU; ...


2

Yes, the memory image saved on the host will contain the LUKS master key, and if a knowledgeable person were to study the memory image, they could extract the key in a usable form. Try resuming the VM. Notice that it picks up where it left off, without asking for a disk encryption password. Since the system can't read the disk without the key, either the ...


2

It is not clear from what kind of attacker your are trying to protect. But to make some guesses what could it be: If the attacker gets inside your VM all files are there in plain because they are transparently decrypted when read. If the attacker is root on the VM host instead he could capture the credentials you need to enter on start of the VM if the ...


1

A guest's memory is still memory, and the host sets it up by allocating it. This means the host has full access to the KVM guest's memory. You would need hardware support to secure a KVM guest from a privileged user on the host. In particular, you would need to utilize Intel SGX to create a secure trusted environment. The newer memory encryption techniques ...


1

If the guest is compromised, can it permanently infect the GPU and its firmware? According to OpenStack documentation, yes. Many hypervisors offer a functionality known as PCI passthrough. This allows an instance to have direct access to a piece of hardware on the node. For example, this could be used to allow instances to access video cards or ...


1

Yes, this can reduce host kernel attack surface area. It can also be useful for isolating devices in the case that you have broken DMAR table and cannot protect from DMA attacks otherwise. This is something I have done in the past for most PCI devices. Some things to consider: Use VFIO, not PCI passthrough VFIO is newer, and will properly isolate devices ...


1

This is a tough question to answer since measuring attack surface is difficult. But let's assume that we 'measure' it by what we think is the amount of processing the untrusted data goes through in some part of the networking stack. Am I right in assuming that with both methods (PCI & USB passthrough), I'm actually reducing the attack surface in the ...


1

It rather depends what you mean by "comparable security". One key difference between a VM and other approaches is that the former simplifies addressing availability; it's possible to migrate a running VM across different hardware nodes, it's easy to snapshot the state of a running VM to a disk image. Ignoring these for now (it possibly makes this too ...


1

Classic VM: There are two kernels, the hypervisor uses CPU feature to emulate a hardware, and the guest kernel is generally unaware that it is running on a virtualized system. This is generally considered to give the best isolation, however giving restricted access to the guest system can be tricky as many security features needed to be enforced by the guest ...


1

I would say as a generalization that bare-metal hypervisor is more secure. As with any system when you add more software you add more attack surface. So let's take any hosted hypervisor out there. Instead of just dealing with the hypervisor attack surface you also have the OS vulnerabilities to worry about.


1

No, Docker is less secure by design, check out the answer on https://security.stackexchange.com/a/148794/39716 OS-level virtualization reuses the kernel-space between virtual machines, and kernel is a much more complicated piece of code, leaving a MUCH larger attack surface - basically the same thing that makes docker super-nice to stack a bunch of VMs ...


1

What is the right way to prevent outgoing attacks since most firewalls only offer protection for incoming attacks? To throttle or drop traffic burst I've tried different modules in iptables. The best of which was hashlimit module. I use it in FORWARD chain. For example, to prevent outgoing TCP SYN traffic burst and limit it to 60 request a minutes use: ...


1

KVM over IP is simply access to physical computer console (screen, keyboard, mouse, USB etc.). iLO is a kind of remote control interface, using which administrator can control the server below the operating system layer, and even below the physical console, BIOS/UEFI etc. If you give iLO access to someone, that person will have the complete control over ...


Only top voted, non community-wiki answers of a minimum length are eligible