7 ms·

I believe it was Theo de Raadt who once said, "Why does everything think that when it comes to writing VM/container software suddenly people gain super human pr

I believe it was Theo de Raadt who once said, "Why does everything think that when it comes to writing VM/container software suddenly people gain super human programming powers and no longer make the same mistakes they make writing operating systems?" (Slightly paraphrasing). While the issue is currently fixed in the .12 and 1.0 versions. I doubt Docker is still completely bullet proof.

xmlninja 12y ago
No software is ever gonna be bullet proof.
- logicallee 12y ago
  Except the software running a tank.
  - valarauca1 12y ago
    I write software that runs on tanks, its not bullet proof. Most the communication protocols just use security though obscurity. If you tell a gear box to shift form 1st to snip it'll do it, and break everything. But when you considered air gap, and physical security surrounding it (12 inches of plate steal, 5 man team with guns, massive main gun), its pretty secure.
    - clhodapp 12y ago
      I think it was a joke... You can fire bullets at the tank and the stuff inside is fine.
      - valarauca1 12y ago
        It is, but vehicles including tanks and other armored things use horribly insecure serial protocols for communication. Which is no joke :\
      - al2o3cr 12y ago
        Only for suitably small values of "bullet". :)
      - baddox 12y ago
        Not unless you're defining "bullets" to exclude things like https://en.wikipedia.org/wiki/Depleted_uranium#Ammunition https://en.wikipedia.org/wiki/Depleted_uranium#Ammunition.
    - dhimes 12y ago
      Except the software running a tank. I write software that runs on tanks Ha! Only on HN...
    - mschulkind 12y ago
      I'm thinking the joke is that, since the software runs inside the tank, which itself is bulletproof, the software is literally bulletproof since you can't shoot it with a bullet.
    - dfc 12y ago
      Modern tanks have steel armor plates that are 12 inches thick?
      - tacticus 12y ago
        i think they measure tank armour as equivalent to RHA steel so it probably isn't steel in large quantities just as good as 300mm of RHA
    - mpyne 12y ago
      I've used important software for submarines. OPSEC limits what I can say, but let's just say I wasn't very impressed.
SEJeff 12y ago
That is why Redhat contributed SELinux support for Docker so you can run with Mandatory Access Control enabled. Docker is a layer, and security is best in multiple layers. One of them will always be broken.
gtjay 12y ago
This phrasing unfairly conflates VM/hypervisor technology and containers. Containers being a pure software technology do require near superhuman ability to secure but VM/hypervisors can lean on chip-level separation. People forget that in-chip memory protection didn't come about for security reasons, memory errors were a particularly dangerous and particularly common kind of bug and the hardware was extended to help with memory isolation. OS session ending memory errors are almost unheard of since operating systems have started fully utilizing the on-chip protection. Programmers didn't become "superhuman" at preventing these errors. For similar reasons it's much easier for hardware-backed virtualization programmers to protect you from malicious business inside a VM than it is for OS or container programmers.
- nhaehnle 12y ago
  You now rely on chip designers being super-human. The real truth is that the difficulty of containment is proportional to the interface that is available to the contained process. You don't need VM or hypervisor technology to build a virtually unbreakable container. You only need to prevent the contained process from using any syscalls at all. Hardware only seems better at this kind of stuff because (a) it's harder to find errata in hardware and (b) the syscall interfaces of commonly used operating systems are much larger than what the hardware offers, and were developed without keeping containability in mind. It is a well known fact that tacking on security features in hindsight is problematic.
  - gtjay 12y ago
    You don't need super-human chip designers because, as you say, "the difficulty of containment is proportional to the interface that is available". Hardware doesn't just seem better because "the syscall interfaces of commonly used operating systems are much larger than what the hardware offers", it is better. It is easier to analyse, has a more limited state-space, has more provable behavior, etc. You can't just argue away the fact that a certain class of error has been all but eliminated by hardware-supported virtual memory. Multi-tasking as we know it today would basically be impossible without it. The reliability of "just get it right" systems like the early Macintosh isn't even comparable to, for example, a modern Linux machine that uses the chip to trap large classes of erroneous memory accesses. Given that we have the above, a case of a class of error that programmers seemed unable to eliminate (practically) eliminated, I'm not really sure what you're arguing. Are you saying that hardware designers of the 80's were superhuman? Okay... maybe Jay Miner...
bcoates 12y ago
All user mode code has been in OS-enforced, security-bounded, per-process VMs that access each other and hardware through virtualized interfaces since forever (well, since the 90s for mainstream microcomputer OSes). "Containers" are just user-accessible support tooling to get creative with how those interfaces work. It really should be much easier to make container software than the entire virtualization infrastructure from scratch, in the same way that it's easier to write tar than a filesystem driver.
mrweasel 12y ago
His words where: "You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes." (http://marc.info/?l=openbsd-misc&m=119318909016582 http://marc.info/?l=openbsd-misc&m=119318909016582) It a wonderful quote by the way, I really like it and it mirrors my reservations regarding some peoples use of visualization. Visualization is perfectly fine, for hardware utilization, ease of deployment and so on, just don't rely on it for additional security, because that's not what it's there for.
- amscanne 12y ago
  I disagree: the hardware virtualization mechanisms provide an extra level of protection. Just like the non-virtualized protection mechanisms do. No virtualization developer is under the impression that it's magical or bulletproof. You rely on the operating system's security mechanisms continuously, and developers work hard to fix bugs and vulnerabilities when they appear. Same goes for virtualization -- the security semantics are just different.
  - mrweasel 12y ago
    >No virtualization developer is under the impression that it's magical or bulletproof. Developers: No, of cause not. Some users however assume that you're automatically safe because you run Vmware/Xen/HyperV whatever.

xmlninja 12y ago

No software is ever gonna be bullet proof.

logicallee 12y ago
Except the software running a tank.
- valarauca1 12y ago
  I write software that runs on tanks, its not bullet proof. Most the communication protocols just use security though obscurity. If you tell a gear box to shift form 1st to snip it'll do it, and break everything. But when you considered air gap, and physical security surrounding it (12 inches of plate steal, 5 man team with guns, massive main gun), its pretty secure.
  - clhodapp 12y ago
    I think it was a joke... You can fire bullets at the tank and the stuff inside is fine.
    - valarauca1 12y ago
      It is, but vehicles including tanks and other armored things use horribly insecure serial protocols for communication. Which is no joke :\
    - al2o3cr 12y ago
      Only for suitably small values of "bullet". :)
    - baddox 12y ago
      Not unless you're defining "bullets" to exclude things like https://en.wikipedia.org/wiki/Depleted_uranium#Ammunition https://en.wikipedia.org/wiki/Depleted_uranium#Ammunition.
  - dhimes 12y ago
    Except the software running a tank. I write software that runs on tanks Ha! Only on HN...
  - mschulkind 12y ago
    I'm thinking the joke is that, since the software runs inside the tank, which itself is bulletproof, the software is literally bulletproof since you can't shoot it with a bullet.
  - dfc 12y ago
    Modern tanks have steel armor plates that are 12 inches thick?
    - tacticus 12y ago
      i think they measure tank armour as equivalent to RHA steel so it probably isn't steel in large quantities just as good as 300mm of RHA
  - mpyne 12y ago
    I've used important software for submarines. OPSEC limits what I can say, but let's just say I wasn't very impressed.

SEJeff 12y ago

That is why Redhat contributed SELinux support for Docker so you can run with Mandatory Access Control enabled. Docker is a layer, and security is best in multiple layers. One of them will always be broken.

gtjay 12y ago

This phrasing unfairly conflates VM/hypervisor technology and containers. Containers being a pure software technology do require near superhuman ability to secure but VM/hypervisors can lean on chip-level separation. People forget that in-chip memory protection didn't come about for security reasons, memory errors were a particularly dangerous and particularly common kind of bug and the hardware was extended to help with memory isolation. OS session ending memory errors are almost unheard of since operating systems have started fully utilizing the on-chip protection. Programmers didn't become "superhuman" at preventing these errors. For similar reasons it's much easier for hardware-backed virtualization programmers to protect you from malicious business inside a VM than it is for OS or container programmers.

nhaehnle 12y ago
You now rely on chip designers being super-human. The real truth is that the difficulty of containment is proportional to the interface that is available to the contained process. You don't need VM or hypervisor technology to build a virtually unbreakable container. You only need to prevent the contained process from using any syscalls at all. Hardware only seems better at this kind of stuff because (a) it's harder to find errata in hardware and (b) the syscall interfaces of commonly used operating systems are much larger than what the hardware offers, and were developed without keeping containability in mind. It is a well known fact that tacking on security features in hindsight is problematic.
- gtjay 12y ago
  You don't need super-human chip designers because, as you say, "the difficulty of containment is proportional to the interface that is available". Hardware doesn't just seem better because "the syscall interfaces of commonly used operating systems are much larger than what the hardware offers", it is better. It is easier to analyse, has a more limited state-space, has more provable behavior, etc. You can't just argue away the fact that a certain class of error has been all but eliminated by hardware-supported virtual memory. Multi-tasking as we know it today would basically be impossible without it. The reliability of "just get it right" systems like the early Macintosh isn't even comparable to, for example, a modern Linux machine that uses the chip to trap large classes of erroneous memory accesses. Given that we have the above, a case of a class of error that programmers seemed unable to eliminate (practically) eliminated, I'm not really sure what you're arguing. Are you saying that hardware designers of the 80's were superhuman? Okay... maybe Jay Miner...

bcoates 12y ago

All user mode code has been in OS-enforced, security-bounded, per-process VMs that access each other and hardware through virtualized interfaces since forever (well, since the 90s for mainstream microcomputer OSes). "Containers" are just user-accessible support tooling to get creative with how those interfaces work. It really should be much easier to make container software than the entire virtualization infrastructure from scratch, in the same way that it's easier to write tar than a filesystem driver.

mrweasel 12y ago

His words where: "You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes." (http://marc.info/?l=openbsd-misc&m=119318909016582 http://marc.info/?l=openbsd-misc&m=119318909016582) It a wonderful quote by the way, I really like it and it mirrors my reservations regarding some peoples use of visualization. Visualization is perfectly fine, for hardware utilization, ease of deployment and so on, just don't rely on it for additional security, because that's not what it's there for.

amscanne 12y ago
I disagree: the hardware virtualization mechanisms provide an extra level of protection. Just like the non-virtualized protection mechanisms do. No virtualization developer is under the impression that it's magical or bulletproof. You rely on the operating system's security mechanisms continuously, and developers work hard to fix bugs and vulnerabilities when they appear. Same goes for virtualization -- the security semantics are just different.
- mrweasel 12y ago
  >No virtualization developer is under the impression that it's magical or bulletproof. Developers: No, of cause not. Some users however assume that you're automatically safe because you run Vmware/Xen/HyperV whatever.