4 ms·

I agree, these things are the future. Containers may be useful for single-tenant partitioning, but no one has managed to produce an OS kernel without an order

I agree, these things are the future. Containers may be useful for single-tenant partitioning, but no one has managed to produce an OS kernel without an order of magnitude more local root security vulnerabilities than the HVM or PV virutualization systems.

contingencies 13y ago
Honestly, on Linux we can reach a similar point now by careful application of existing tools. For example, by whitelisting syscalls, devices, hardware and network resources and access patterns, in combination with containers. Most of the challenge is automating that process adequately, which is really nothing more than traditional code profiling meets existing policy-based kernel-level security toolkits meets containers meets development processes (ie. build/test/release). After ~3 years' with LXC, I believe that most of the attack surfaces are reasonably well understood and/or not required for most code to function. Sure, there will be kernel-level vulnerabilities, but they won't be exposed to such a broad range of userland applications. With security you also get so much more insight, power and predictability with regards to resource profiling than with paravirtualized solutions. Real kernel-level metrics versus load! Think of the impact for operations/capacity planning. So... short soundbite to summarize? Docker is a toy compared to where we are going.
- shykes 13y ago
  Hi, I'm the author of Docker. I agree with everything you said about lxc, but I'm not sure how you reached the conclusion that docker is a toy. Since Docker is a portability layer on top of lxc, it automatically benefits from all the awesome work happening in the kernel. Or do you just use "toy" as a synonymous for "userland"?
  - contingencies 13y ago
    I mean no disrespect to docker! It's a great step, though has its limitations. I am talking conceptually about the whole direction the lightweight virt/app-level portability (relative infrastructure independence) thing is going. My point is that the impact that continuing developments in this general area are going to have on security, development and operations processes is probably extreme... and I believe seriously under-considered by the community at present.
    - shykes 13y ago
      Author's susceptibility aside :) You are totally right. Now that lightweight virt is broadly available on the server, we are going to see a very, very big change in how computing is done on the server, and all of today's tools (docker included) are going to look cute and primitive compared to what we'll have a in a couple years. I can't wait :)
      - contingencies 13y ago
        I have been working in the same direction in private for my current employer, are near a solution encompassing all of the above, and may open source at some point. In terms of potential collaboration, what I would really like from docker is a single page, frequently revised summary page of features and efforts within the docker world. That would help me to get in touch with people to share info if we are facing similar challenges. Right now it seems I would have to spend a lot of time monitoring things; time which doesn't exist. (He says, off to a sitar lesson...)
        shykes 13y ago
        Yes, we need that. For now here is what we have: 1) An ad-hoc compilation of cool stuff maintained by Ken Cochrane: https://github.com/dotcloud/docker/issues/614 https://github.com/dotcloud/docker/issues/614 2) All sorts of interesting software projects distributed as docker containers: http://index.docker.io http://index.docker.io 3) A highly active IRC channel, #docker@freenode where many cool applications of docker are being discussed
        porker 13y ago
        If you do OS it, I'd be very interested to hear!
  - davidstrauss 13y ago
    Just a note as the author of the Linux Journal article, I absolutely would have mentioned Docker if I had written the article now. Unfortunately, the article only recently made it to publication (and now post-paywall) despite my having written it in January.

contingencies 13y ago

Honestly, on Linux we can reach a similar point now by careful application of existing tools. For example, by whitelisting syscalls, devices, hardware and network resources and access patterns, in combination with containers. Most of the challenge is automating that process adequately, which is really nothing more than traditional code profiling meets existing policy-based kernel-level security toolkits meets containers meets development processes (ie. build/test/release). After ~3 years' with LXC, I believe that most of the attack surfaces are reasonably well understood and/or not required for most code to function. Sure, there will be kernel-level vulnerabilities, but they won't be exposed to such a broad range of userland applications. With security you also get so much more insight, power and predictability with regards to resource profiling than with paravirtualized solutions. Real kernel-level metrics versus load! Think of the impact for operations/capacity planning. So... short soundbite to summarize? Docker is a toy compared to where we are going.

shykes 13y ago
Hi, I'm the author of Docker. I agree with everything you said about lxc, but I'm not sure how you reached the conclusion that docker is a toy. Since Docker is a portability layer on top of lxc, it automatically benefits from all the awesome work happening in the kernel. Or do you just use "toy" as a synonymous for "userland"?
- contingencies 13y ago
  I mean no disrespect to docker! It's a great step, though has its limitations. I am talking conceptually about the whole direction the lightweight virt/app-level portability (relative infrastructure independence) thing is going. My point is that the impact that continuing developments in this general area are going to have on security, development and operations processes is probably extreme... and I believe seriously under-considered by the community at present.
  - shykes 13y ago
    Author's susceptibility aside :) You are totally right. Now that lightweight virt is broadly available on the server, we are going to see a very, very big change in how computing is done on the server, and all of today's tools (docker included) are going to look cute and primitive compared to what we'll have a in a couple years. I can't wait :)
    - contingencies 13y ago
      I have been working in the same direction in private for my current employer, are near a solution encompassing all of the above, and may open source at some point. In terms of potential collaboration, what I would really like from docker is a single page, frequently revised summary page of features and efforts within the docker world. That would help me to get in touch with people to share info if we are facing similar challenges. Right now it seems I would have to spend a lot of time monitoring things; time which doesn't exist. (He says, off to a sitar lesson...)
      - shykes 13y ago
        Yes, we need that. For now here is what we have: 1) An ad-hoc compilation of cool stuff maintained by Ken Cochrane: https://github.com/dotcloud/docker/issues/614 https://github.com/dotcloud/docker/issues/614 2) All sorts of interesting software projects distributed as docker containers: http://index.docker.io http://index.docker.io 3) A highly active IRC channel, #docker@freenode where many cool applications of docker are being discussed
      - porker 13y ago
        If you do OS it, I'd be very interested to hear!
- davidstrauss 13y ago
  Just a note as the author of the Linux Journal article, I absolutely would have mentioned Docker if I had written the article now. Unfortunately, the article only recently made it to publication (and now post-paywall) despite my having written it in January.