4 ms·

Make it clean and fast and you'll have a compelling secure host OS for VMs. One problem that would be good to address (and maybe it is) is making it really har

by api 11y ago

Make it clean and fast and you'll have a compelling secure host OS for VMs. One problem that would be good to address (and maybe it is) is making it really hard to dump the memory of a VM. We don't have homomorphic encryption yet, so right now if you dump a VM you own any secrets it holds. So at the very least this should be made as hard as possible on production VM hosts.

jodrellblank 11y ago
right now if you dump a VM you own any secrets it holds Unrelated to OpenBSD but related to VM security from administrators - https://4sysops.com/archives/shielded-vms-in-windows-server-2016-hyper-v/ https://4sysops.com/archives/shielded-vms-in-windows-server-...
- tyho 11y ago
  This is not very useful, it is a security policy change. The previous post mentioned homomorphic encryption. This is a method of performing computation on the cipher text. If this were implemented, then you could potentially create VM's where even in the event of a hypervisor compromise, dumping the plaintext memory of guests is not possible. If you can take a memory dump of the host sytem, you can from that devise the encryption key for the disk encryption with the M$ solution to this issue.
  - deleted 11y ago
    [deleted]
x0x0 11y ago
What does making it hard for the host to dump vm memory buy you? It seems like if the host wants, there's virtually endless things they can do. iow, you have to trust the host.
- doomrobo 11y ago
  Agreed. If you own the host, you win. The point is to make it difficult to own the host from within the VM, not vice-versa.
  - ams6110 11y ago
    If I'm running a guest on a hosting service, I'd like it if I didn't have to trust the host. Technically, that's maybe not possible right now, but it's not like it's a goal we should just shrug off.
    - doomrobo 11y ago
      I don't think that will ever be possible, barring some sort of quantum memory where reading clobbers data.
      - toast0 11y ago
        To be pedantic, reading dram does clobber the data; but it gets re written as part of the read cycle.
- api 11y ago
  Things are not insecure or secure. Things are secure to varying degrees; nothing is perfectly so and few things are totally not. (... and anyone who claims anything is totally secure is delusional.) Making it hard buys you some resistance to less skilled attackers. Since skill tends to obey a power law distribution, this is most attackers. Make it as hard as possible and you get more and more protection from more and more attackers, and so on. Your average attacker doesn't know enough to bust out x86 assembly language to inject root code into the kernel and dump a VM's RAM. So make it so you have to do this, and you've ruled out your average attacker. The average attacker will only 'dd' the VMs' disks, which if they've encrypted data at rest will not get them the crown jewels. But make it easy to dump VM RAM and you've exponentially increased the damage from the average attacker (due to power law distribution of skill).
  - hueving 11y ago
    Whatever stupid barriers you put up will just be automated away in common tools. Then all you have is something more complex than it needs to be that probably has bugs and vulnerabilities because you made it convoluted.
  - blibble 11y ago
    every piece of vm software has a save/snapshot button which will save the state of the ram/cpu to disk.
  - geofft 11y ago
    It only takes one attacker (or curious college student) to figure it out and post it on GitHub, and then your average attacker can bust out all the assembly language required without actually knowing it. For comparison -- does your average Windows attacker know how to cryptanalyze the LM hash function? No, but they can run the tool just the same. There are absolutely places where your the general argument holds water: "no security by obscurity" is a simplistic framework, and ignores a much more reasonable and also simpler framework of costs and incentives. In several cases, the costs of figuring out something obscure outweigh the potential incentives of breaking it. But in this particular case, there are no marginal costs to the attacker. Once someone somewhere invests the time to figure it out, for any motivation including curiosity, the defense is immediately worthless for everyone.
alphonse23 11y ago
homomorphic encryption exists. It's just slow, though it depends on what you consider slow: https://github.com/shaih/HElib https://github.com/shaih/HElib
mkj 11y ago
There's Intel SGX which give secure enclaves through hardware, could probably do unreadable VMs.
- amluto 11y ago
  No, or at least not in the traditional sense. SGX is strictly CPL 3, i.e. user mode. You could plausibly stick a unikernel inside.
  - mkj 11y ago
    Oh I'd missed that, thanks. Maybe uclinux...? Or qemu - more nesting!

by api 11y ago

jodrellblank 11y ago

right now if you dump a VM you own any secrets it holds Unrelated to OpenBSD but related to VM security from administrators - https://4sysops.com/archives/shielded-vms-in-windows-server-2016-hyper-v/ https://4sysops.com/archives/shielded-vms-in-windows-server-...

tyho 11y ago
This is not very useful, it is a security policy change. The previous post mentioned homomorphic encryption. This is a method of performing computation on the cipher text. If this were implemented, then you could potentially create VM's where even in the event of a hypervisor compromise, dumping the plaintext memory of guests is not possible. If you can take a memory dump of the host sytem, you can from that devise the encryption key for the disk encryption with the M$ solution to this issue.
- deleted 11y ago
  [deleted]

x0x0 11y ago

What does making it hard for the host to dump vm memory buy you? It seems like if the host wants, there's virtually endless things they can do. iow, you have to trust the host.

doomrobo 11y ago
Agreed. If you own the host, you win. The point is to make it difficult to own the host from within the VM, not vice-versa.
- ams6110 11y ago
  If I'm running a guest on a hosting service, I'd like it if I didn't have to trust the host. Technically, that's maybe not possible right now, but it's not like it's a goal we should just shrug off.
  - doomrobo 11y ago
    I don't think that will ever be possible, barring some sort of quantum memory where reading clobbers data.
    - toast0 11y ago
      To be pedantic, reading dram does clobber the data; but it gets re written as part of the read cycle.
api 11y ago
Things are not insecure or secure. Things are secure to varying degrees; nothing is perfectly so and few things are totally not. (... and anyone who claims anything is totally secure is delusional.) Making it hard buys you some resistance to less skilled attackers. Since skill tends to obey a power law distribution, this is most attackers. Make it as hard as possible and you get more and more protection from more and more attackers, and so on. Your average attacker doesn't know enough to bust out x86 assembly language to inject root code into the kernel and dump a VM's RAM. So make it so you have to do this, and you've ruled out your average attacker. The average attacker will only 'dd' the VMs' disks, which if they've encrypted data at rest will not get them the crown jewels. But make it easy to dump VM RAM and you've exponentially increased the damage from the average attacker (due to power law distribution of skill).
- hueving 11y ago
  Whatever stupid barriers you put up will just be automated away in common tools. Then all you have is something more complex than it needs to be that probably has bugs and vulnerabilities because you made it convoluted.
- blibble 11y ago
  every piece of vm software has a save/snapshot button which will save the state of the ram/cpu to disk.
- geofft 11y ago
  It only takes one attacker (or curious college student) to figure it out and post it on GitHub, and then your average attacker can bust out all the assembly language required without actually knowing it. For comparison -- does your average Windows attacker know how to cryptanalyze the LM hash function? No, but they can run the tool just the same. There are absolutely places where your the general argument holds water: "no security by obscurity" is a simplistic framework, and ignores a much more reasonable and also simpler framework of costs and incentives. In several cases, the costs of figuring out something obscure outweigh the potential incentives of breaking it. But in this particular case, there are no marginal costs to the attacker. Once someone somewhere invests the time to figure it out, for any motivation including curiosity, the defense is immediately worthless for everyone.

alphonse23 11y ago

homomorphic encryption exists. It's just slow, though it depends on what you consider slow: https://github.com/shaih/HElib https://github.com/shaih/HElib

mkj 11y ago

There's Intel SGX which give secure enclaves through hardware, could probably do unreadable VMs.

amluto 11y ago
No, or at least not in the traditional sense. SGX is strictly CPL 3, i.e. user mode. You could plausibly stick a unikernel inside.
- mkj 11y ago
  Oh I'd missed that, thanks. Maybe uclinux...? Or qemu - more nesting!