434

No, Docker containers are not more secure than a VM. Quoting Daniel Shapira: In 2017 alone, 434 linux kernel exploits where found, and as you have seen in this post, kernel exploits can be devastating for containerized environments. This is because containers share the same kernel as the host, thus trusting the built-in protection mechanisms alone isn’t ...


89

Separate development and production It is usual practice to give developers local admin / root rights on their workstation. However, developers should only have access to development environments and never have access to live data. Sys-admins - who do have access to production - should have much more controlled workstations. Ideally, sys-admin workstations ...


75

Saying either a VM or Docker is more secure than the other is a massive over simplification. VM provides hardware virtualization; the hypervisor emulates hardware so that the guest kernel thinks it is running on its own machine. This type of virtualization is easier to isolate from one another. If your primary concern for virtualization is isolation (you ...


65

By using the same VM for browsing, word documents, and email, you are exposing all of your data to the same level of risk. Instead of doing all of this activity in the VM, consider doing your browsing and email in the VM, but the contract work and bookkeeping stuff on the host OS. That way if you get phished, the attack is limited to the VM, and can't do ...


61

If the kernel is compromised in the container, the host is compromised. Ostensibly, a compromised container should not be able to harm the host. However, container security is not great, and there are usually many vulnerabilities that allow a privileged container user to compromise the host. In this way, containers are often less secure than full virtual ...


55

Theoretically, the guest system is totally isolated by the VM and cannot even "see" the host, let alone attack it; so the guest cannot break out of the VM. Of course, in practice, it has occasionally happened (web archive link). An attack requires exploiting a security issue (i.e. a programming bug which turns out to have nasty consequences) in the VM ...


41

So this answer is from the point of a developer. Keep that in mind. First, not having "local admin" rights on my own machine is a sign that I should look for a job elsewhere. It's nearly impossible to write code, fiddle with stuff, and maintain a toolchain if you have to ask permission every-time you need to update (or test out) a new dependency or ...


35

(Caveat: I certainly don't claim that HAVEGE lives up to its claims. I have not checked their theory or implementation.) To get randomness, HAVEGE and similar systems feed on "physical events", and in particular on the timing of physical events. Such events include occurrences of hardware interrupts (which, in turn, gathers data about key strokes, mouse ...


34

There is no simple answer to this question. VM software is still software and has vulnerabilities that can be targeted and thus, in theory at least, exploited to do more harm. Running an infected VM with access to your network also opens up potential attack vectors. Another interesting point to consider is that sufficiently advanced malware could be VM-...


33

No - because your VM is inside a machine connected to the Internet it is not safe. It is protected, yes, but that protection is only as good as the protection the host machine provides. An attack could compromise the host machine via its connection, subvert the hypervisor and compromise your VM. Read this question and others in the Related sidebar to the ...


29

Are virtual machines safe for this? The answer is the same as for a lot of questions of the form "Is X safe?": no, it's not absolutely safe. As described elsewhere, bugs in the virtual machine or poor configuration can sometimes enable the malware to escape. So, at least in principle, sophisticated malware might potentially be able to detect that it's ...


27

Yes, it can. Any data stored on the virtual hard drives of the virtual machines is stored on the hard drive of the host system. When any VMs are in "suspended" state, their RAM content is also saved on the hosts hard drive. Any malware which can access these files can read and modify their content. Another attack vector would be to target the hypervisor ...


25

General advice Any program written in Java Add -Djava.security.egd=file:///dev/urandom switch or -Djava.security.egd=file:/dev/./urandom to the command line invocation used to start the Java process. (Without this, Java uses /dev/random to seed its SecureRandom class, which can cause Java code to block unexpectedly.) Alternatively, in the $JAVA_HOME/...


24

The host machine can impact and alter whatever it wishes in the guest VM. The host can read and write all the memory of the guest, stop and restart it on a per-instruction basis, and, by nature, sees every single data byte which enters or exits the guest. There is nothing which the OS in a guest VM can do to protect itself against an hostile host. Thus, if ...


24

As you correctly stated, Docker uses "Operating-system-level virtualization". You can think of this (if you are a *nix fan) as a fancy form of chroot. By harnessing features and functionality built into the OS, Docker acts as a director for containers. The software's view of the OS is dictated by Docker. The same kernel is used across all containers. So ...


24

The references you mention don't conflict with each other. The first one claims for Meltdown that "Fully virtualized machines are not affected". The second one claims that the product is "vulnerable to Bounds Check Bypass and Branch Target Injection issues". These issues are not the Meltdown but the Spectre vulnerability. Or to summarize: CVE-2017-5753 - ...


22

I have not yet seen any in-the-wild malware that was designed to infect a host machine from within a VM. I expect that most malware simply wouldn't care whether it is running on the bare hardware or within a VM since it can achieve its goals equally well in both cases. It's probably safe to assume that malware won't escape a VM simply because it has no ...


22

Whether or not it contains an exploit, specifically, is irrelevant in the broader question of whether an OVA file can be malicious. The answer to the broader question is yes, absolutely. The Open Virtualization Format specification gives you an idea of some of the potential vectors, but the obvious one is that it could map your entire OS disk to the VM and ...


19

Everything: As root, just do this: rm /dev/random mknod /dev/random c 1 9 Now /dev/random will actually access the same underlying logic as /dev/urandom. After this change, both /dev/random and /dev/urandom will draw from the non-blocking pool. The non-blocking pool will draw from the blocking pool, which the system will still fill.


19

Using a virtual machine is a safer way to study malware than running it on a normal machine - the main reason being that you can wipe and start over from a known fresh image at any time. Isolation is also key, though - if your virtual machines are connected to your network they will be able to spread malware just as if they were physical machines, so either ...


19

From a developer's point of view: Your job is to prevent change (known bugs and vulnerabilities are better than unknown, right?), but mine is to change things. This puts us at an impasse. My job is to create/change things. If your policy prevents that, then, like any other obstacle, a part of my job is finding a way around that. Which do you think is ...


18

Firstly, there is no guarantee you'll even be able to run a VM inside a VM. It may seem obvious but it is by no means certain it will even work. This is because VM's may rely on virtualization features of your hardware which are not exposed inside the VM itself. Secondly, why two, why not three, four, five, etc... There is such a thing as overkill security. ...


18

As the article describes it, VM introspection looks like inspecting the contents of the VM in real-time, to see that everything appears to be "in order". Virtual machines allow for such inspection without consent or knowledge of the guest system. This contrasts with classic antimalware software on physical systems: the antimalware runs on the system itself, ...


18

In context of a Windows setup, a hypervisor such as VirtualBox, VMware helps isolate your guest from the host (the main installation of your OS). This is a considerate move in terms of Security, if you're dealing with activities or files/software that pose a risk to compromise your data. One example would be for Security Analysts, who is analyzing malware ...


17

Yes, if you strictly bond yourself to some (absolutely sane) security rules: Use a completely different operating system for the host and for the guest. For example, malwares which will infect your Windows guest are unlikely to infect or even attack your Linux host. Do not use similar operating systems on your network than the guest. Again, your Windows ...


16

All of this depends on the hardware (physical or virtual) available to your VM. rng-tools can only get entropy from the sources available to it. If your virtual machine has no available sources of entropy for rng-tools to use then you'll be no better off. Some virtualization systems are however able to make hardware sourced entropy available to guests ...


16

Highly customized and patched hypervisors, sandboxes around said hypervisors to mitigate breakouts, and heavy monitoring. Of course, any given server only hosts so many VMs, so a breakout is fundamentally limited to a finite number of guests, if it's able to get past the protections outside the hypervisor. For example, QEMU can be compiled with a hardened ...


16

Any file can contain an exploit. Whether it works or not, or if it requires a loader, is another story. For example, if there's a buffer overflow vulnerability in the processing of .ova files, then yes, it could contain an exploitable vulnerability. It all depends on whether or not you have a vulnerable application which processes the file that contains ...


16

My understanding, first off, is that the OS / hypervisor patch only mitigates Meltdown, not Spectre. Second, you patch the hypervisor to prevent a VM from reading memory belonging to the kernel of the hypervisor. You patch the guest OS to prevent a process from reading memory belonging to the kernel of the guest OS. My understanding is that they are ...


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