3 ms·

I think that's an extremely uncharitable view on containers. There has been a massive amount of work put into securing containers for a variety of use cases usi

I think that's an extremely uncharitable view on containers. There has been a massive amount of work put into securing containers for a variety of use cases using both layers available and by adding to the kernel.

masklinn 7y ago
> I think that's an extremely uncharitable view on containers. It's an objective one. > There has been a massive amount of work put into securing containers for a variety of use cases using both layers available and by adding to the kernel. That doesn't change the fact that security was never the primary goal for containers, so secure containers were and are a bunch of tricks, kludges and prayers being built up in the hope that eventually all the holes in the model will be patched. The "Making containers safer"[lwn][hn] talk was literally two days ago. Note how it says safer, not safe. [lwn] https://lwn.net/SubscriberLink/796700/9bc9daa32a8fe499/ https://lwn.net/SubscriberLink/796700/9bc9daa32a8fe499/ [hn] https://news.ycombinator.com/item?id=20764355 https://news.ycombinator.com/item?id=20764355
- pbhjpbhj 7y ago
  Of course it says safer, if someone tells you something is entirely safe you know they're lying.
- roblabla 7y ago
  Can you please quote how containers are not built with security in mind? What would even be the point of user namespacing, network namespaces, filesystem namespaces, etc... if not security?
  - yters 7y ago
    I recently took a course on how cgroups and namespaces work, and can be combined to create containers, and my impression is security is a huge kludge. For example, the capabilities are just a seeming random assortment of different permissions, with a big dumping ground in the admin capability. It's hard to see how such a system can be reliably secured. Plus, it's all open source with a couple core contributors. What's to stop some state agency inserting its code into the core? No way to review everything, and a suitably clever developer can place a backdoor somewhere in all of the millions of lines of code. So, I must agree that security is not really at the forefront of Linux or container technology.
    - MaxBarraclough 7y ago
      > my impression is security is a huge kludge Docker itself could be called a huge kluge, at least compared to Solaris 'zones' and FreeBSD 'jails'. They're similar to containers, but are supported directly by the kernel, whereas Docker has to pull together different kernel features to create its abstraction. [0] > What's to stop some state agency inserting its code into the core? No way to review everything 1. This isn't a point about containers, it's a point about Free and Open Source software in general. Do you avoid all Open Source software when security matters? 2. I'm pretty sure the Linux kernel folks review everything, and I imagine the Docker folks do too 3. You're implicitly assuming that closed-source software is safe from government pressure. It is not. [0] https://blog.jessfraz.com/post/containers-zones-jails-vms/ https://blog.jessfraz.com/post/containers-zones-jails-vms/
      - yters 7y ago
        Nothing is safe from government pressure. But, at least with local closed source we know it's going to just be our government pressure. Otherwise, it could be any actor, which may be less friendly towards us.
        MaxBarraclough 7y ago
        > with local closed source we know it's going to just be our government pressure We don't. Companies that produce proprietary code are not immune from attacks on their repository, and are more vulnerable to, say, bribery. They're also more vulnerable to attacks on their distributed binaries - users do not have the option to compile from source, so you compromise every user this way. Proprietary software is also far more likely to embed 'telemetry' spying, or to use sloppy security practices and rely on security-by-obscurity. Authors of Free and Open Source software know that they (generally at least [0]) cannot get away with this kind of thing. It simply isn't true that proprietary software is more trustworthy than FOSS. If anything, the opposite appears to be true. [0] https://news.ycombinator.com/item?id=14754740 https://news.ycombinator.com/item?id=14754740
        7y ago
  - MaxBarraclough 7y ago
    Look at how the cloud providers offer support for containers. Do they ever offer to run your container in the same VM as those of other customers? They never do this. For secure isolation, they only trust VM isolation. It seems unlikely that this will change. > What would even be the point of user namespacing, network namespaces, filesystem namespaces, etc... if not security? They're for installation/configuration/administration. They allow you to run multiple applications on one Linux VM, and to configure them independently, almost as if you were running multiple VMs (with the advantage of lower overheads - only one instance of the kernel). Kubernetes puts this to good use, letting you treat application deployments as commodities across your cluster. Containers do not offer secure isolation. They are by nature much leakier than the isolation VMs can offer. The Docker folks still treat isolation-failures as bugs, of course. (Well, ignoring things like the way 'uptime' gives the uptime of the underlying machine, and not of your container.)
    - Huggernaut 7y ago
      There are many services that run applications colocated on VMs in containers. I don't disagree they are leakier abstractions but they can still satisfy a wide variety of workload security needs.
- Huggernaut 7y ago
  It is not objective by any stretch of the imagination. I suppose when security enhancements are made to any other system to make them safer (i.e. everything in the realm of security), you apply the same logic? Subjective.

masklinn 7y ago

> I think that's an extremely uncharitable view on containers. It's an objective one. > There has been a massive amount of work put into securing containers for a variety of use cases using both layers available and by adding to the kernel. That doesn't change the fact that security was never the primary goal for containers, so secure containers were and are a bunch of tricks, kludges and prayers being built up in the hope that eventually all the holes in the model will be patched. The "Making containers safer"[lwn][hn] talk was literally two days ago. Note how it says safer, not safe. [lwn] https://lwn.net/SubscriberLink/796700/9bc9daa32a8fe499/ https://lwn.net/SubscriberLink/796700/9bc9daa32a8fe499/ [hn] https://news.ycombinator.com/item?id=20764355 https://news.ycombinator.com/item?id=20764355

pbhjpbhj 7y ago
Of course it says safer, if someone tells you something is entirely safe you know they're lying.
roblabla 7y ago
Can you please quote how containers are not built with security in mind? What would even be the point of user namespacing, network namespaces, filesystem namespaces, etc... if not security?
- yters 7y ago
  I recently took a course on how cgroups and namespaces work, and can be combined to create containers, and my impression is security is a huge kludge. For example, the capabilities are just a seeming random assortment of different permissions, with a big dumping ground in the admin capability. It's hard to see how such a system can be reliably secured. Plus, it's all open source with a couple core contributors. What's to stop some state agency inserting its code into the core? No way to review everything, and a suitably clever developer can place a backdoor somewhere in all of the millions of lines of code. So, I must agree that security is not really at the forefront of Linux or container technology.
  - MaxBarraclough 7y ago
    > my impression is security is a huge kludge Docker itself could be called a huge kluge, at least compared to Solaris 'zones' and FreeBSD 'jails'. They're similar to containers, but are supported directly by the kernel, whereas Docker has to pull together different kernel features to create its abstraction. [0] > What's to stop some state agency inserting its code into the core? No way to review everything 1. This isn't a point about containers, it's a point about Free and Open Source software in general. Do you avoid all Open Source software when security matters? 2. I'm pretty sure the Linux kernel folks review everything, and I imagine the Docker folks do too 3. You're implicitly assuming that closed-source software is safe from government pressure. It is not. [0] https://blog.jessfraz.com/post/containers-zones-jails-vms/ https://blog.jessfraz.com/post/containers-zones-jails-vms/
    - yters 7y ago
      Nothing is safe from government pressure. But, at least with local closed source we know it's going to just be our government pressure. Otherwise, it could be any actor, which may be less friendly towards us.
      - MaxBarraclough 7y ago
        > with local closed source we know it's going to just be our government pressure We don't. Companies that produce proprietary code are not immune from attacks on their repository, and are more vulnerable to, say, bribery. They're also more vulnerable to attacks on their distributed binaries - users do not have the option to compile from source, so you compromise every user this way. Proprietary software is also far more likely to embed 'telemetry' spying, or to use sloppy security practices and rely on security-by-obscurity. Authors of Free and Open Source software know that they (generally at least [0]) cannot get away with this kind of thing. It simply isn't true that proprietary software is more trustworthy than FOSS. If anything, the opposite appears to be true. [0] https://news.ycombinator.com/item?id=14754740 https://news.ycombinator.com/item?id=14754740
        7y ago
- MaxBarraclough 7y ago
  Look at how the cloud providers offer support for containers. Do they ever offer to run your container in the same VM as those of other customers? They never do this. For secure isolation, they only trust VM isolation. It seems unlikely that this will change. > What would even be the point of user namespacing, network namespaces, filesystem namespaces, etc... if not security? They're for installation/configuration/administration. They allow you to run multiple applications on one Linux VM, and to configure them independently, almost as if you were running multiple VMs (with the advantage of lower overheads - only one instance of the kernel). Kubernetes puts this to good use, letting you treat application deployments as commodities across your cluster. Containers do not offer secure isolation. They are by nature much leakier than the isolation VMs can offer. The Docker folks still treat isolation-failures as bugs, of course. (Well, ignoring things like the way 'uptime' gives the uptime of the underlying machine, and not of your container.)
  - Huggernaut 7y ago
    There are many services that run applications colocated on VMs in containers. I don't disagree they are leakier abstractions but they can still satisfy a wide variety of workload security needs.
Huggernaut 7y ago
It is not objective by any stretch of the imagination. I suppose when security enhancements are made to any other system to make them safer (i.e. everything in the realm of security), you apply the same logic? Subjective.