4 ms·

Containers are nice for putting some distance between the compromised app and the OS. Especially useful when combined with a system for mandatory access control

by lholden 13y ago

Containers are nice for putting some distance between the compromised app and the OS. Especially useful when combined with a system for mandatory access controls (SELinux, Smack, etc). If you can attempt to limit the exposure of a compromise... you should! Having said that... If someone has enough determination, they will manage to compromise your system regardless of how 'secure' it's has been made. :) I generally like to use containers in addition to a virtual machine. I do find it a bit shocking when I see a company offering up containers as an alternative to a VM though. I suppose it's a compromise some companies are willing to make for the additional performance.

zx2c4 13y ago
> Containers are nice for putting some distance between the compromised app and the OS. Some distance. But now a days when you can own the kernel, that distance shrinks to zero. I just saw these a few seconds ago: http://grsecurity.net/~spender/logs2.txt http://grsecurity.net/~spender/logs2.txt https://twitter.com/grsecurity/status/335963659337601024 https://twitter.com/grsecurity/status/335963659337601024
- lholden 13y ago
  > Some distance. But now a days when you can own the kernel, that distance shrinks to zero. I am certainly not disagreeing :). I do wonder how well the exploit would have worked if the system were also locked down with SELinux/Smack. Not that MACs are bulletproof, but again... more distance. In the end though, the only secure system is one that's not powered. :)
  - zx2c4 13y ago
    > I do wonder how well the exploit would have worked "the"? > locked down with SELinux/Smack If you're executing in kernel mode, then you can just disable these. It might be more interesting to point to the efficacy of various exploits on a Grsec/PaX kernel, however. > In the end though, the only secure system is one that's not powered. That's silly. Sure, airgap your sensitive stuff. But there's a reasonable level of security you can achieve that's far beyond what docker provides, while still retaining a flexible and reasonable computing environment. For example, Xen's xl tool makes making quick and cheap VM containers very simple.
    - lholden 13y ago
      > "the"? Now you are just nitpicking :) "the" meaning, you gave me an example. > If you're executing in kernel mode,.....Grsec/PaX kernel, however. SELinux has a lot of overlap with grsec providing many of the same benefits while being more widely available. The flow of an exploit: 1) entry into a system (app compromise, shell access), 2) inserting/uploading of executable data, 3) execution of said data granting further access (Ex, exploiting a kernel bug, adding a backdoor, manipulating the host system in some way). The goals of Grsec/SELinux, and marking data memory as non execute (NX bit, PaX, Exec Shield) are aimed at preventing #2 and #3. The idea is the prevention of access escalation in the first place. On PaX, the kernel supports utilizing the NX bit on x86-64 and has for quite a while now. Not using a system supporting the NX bit or at least PaX/Exec Shield is pretty stupid. > But there's a reasonable level of security you can achieve that's far beyond what docker provides I had already agreed with you on VMs... no reason to argue this point. :) Since you mention VMs again however, I will also note that VMs are not entirely isolated from the host system. A Xen (as your example) exploit as an example: http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html http://lists.xen.org/archives/html/xen-announce/2012-06/msg0...
      - zx2c4 13y ago
        > you gave me an example. Ahh sorry. Well to continue along that example, evidently it breaks out of lots of things -- https://grsecurity.net/~spender/logs.txt https://grsecurity.net/~spender/logs.txt > On PaX, the kernel supports utilizing the NX bit on x86-64 and has for quite a while now. Not using a system supporting the NX bit or at least PaX/Exec Shield is pretty stupid. Not going to try to parse this, but you appear to be very mistaken. Wikipedia PaX. > VMs are not entirely isolated from the host system Correct, hence the parenthetical in the OP. That sysret bug was a great one.
        lholden 13y ago
        > Not going to try to parse this, but you appear to be very mistaken. Wikipedia PaX. On PaX https://en.wikipedia.org/wiki/PaX#Executable_space_protections https://en.wikipedia.org/wiki/PaX#Executable_space_protectio... "The major feature of PaX is the executable space protection it offers. These protections take advantage of the NX bit on certain processors to prevent the execution of arbitrary code. This staves off attacks involving code injection or shellcode. On IA-32 CPUs where there is no NX bit, PaX can emulate the functionality of one in various ways." And then on NX bit support on Linux: https://en.wikipedia.org/wiki/NX_bit#Linux https://en.wikipedia.org/wiki/NX_bit#Linux "The Linux kernel currently supports the NX bit on x86-64 CPUs and on x86 processors that implement it, such as the current 64-bit CPUs of AMD, Intel, Transmeta and VIA. The support for this feature in the 64-bit mode on x86-64 CPUs was added in 2004 by Andi Kleen, and later the same year, Ingo Molnar added support for it in 32-bit mode on 64-bit CPUs. These features have been in the stable Linux kernel since release 2.6.8 in August 2004." PaX also provides a few other features but the big defining one has been the NX bit support. Not sure why you seem to think I am mistaken in what I said.
- shykes 13y ago
  The real value of containers is not security (although lxc does include robust security mechanisms), it's the streamlining of application deployment. If you don't trust lxc to sandbox untrusted code, don't! Just deploy 1 production container per VM, or even per physical machine. But maybe you don't mind running multiple containers on your local dev vm or on your staging machine - I know I don't. What containers give you is a constant payload which can be moved across very different hardware setups, from the most shared to the most isolated.
  - zx2c4 13y ago
    > it's the streamlining of application deployment. I always liked the idea of nicely integrating with the environment and utilizing the features of package managers, the file system, users, and all the rest of the niceties we have at our disposal. "I don't know how to organize a bunch of things together!" seems like a silly reason to containerize every component into a separate root fs. But on the other hand, I can imagine this work flow does have some merit, and some folks save a lot of time and energy and potential headaches just popping things in containers.
    - shykes 13y ago
      > "I don't know how to organize a bunch of things together!" seems like a silly reason to containerize every component into a separate root fs. One good reason to separate every component is that it facilitates moving them to separate machines down the road, or scaling them separately. Another good reason is that it reduces the out-of-band requirements of the components. "all the niceties" you have at your disposal may very well be specific to your distro, or your site setup. By contrast, docker containers only require docker, which is a single binary file. A developer needs to know his component will run anywhere, not just on your particular setup.
- manku_timma 13y ago
  Also, In a private PaaS'ish environment, docker's container abstraction is very useful.

by lholden 13y ago

zx2c4 13y ago

> Containers are nice for putting some distance between the compromised app and the OS. Some distance. But now a days when you can own the kernel, that distance shrinks to zero. I just saw these a few seconds ago: http://grsecurity.net/~spender/logs2.txt http://grsecurity.net/~spender/logs2.txt https://twitter.com/grsecurity/status/335963659337601024 https://twitter.com/grsecurity/status/335963659337601024

lholden 13y ago
> Some distance. But now a days when you can own the kernel, that distance shrinks to zero. I am certainly not disagreeing :). I do wonder how well the exploit would have worked if the system were also locked down with SELinux/Smack. Not that MACs are bulletproof, but again... more distance. In the end though, the only secure system is one that's not powered. :)
- zx2c4 13y ago
  > I do wonder how well the exploit would have worked "the"? > locked down with SELinux/Smack If you're executing in kernel mode, then you can just disable these. It might be more interesting to point to the efficacy of various exploits on a Grsec/PaX kernel, however. > In the end though, the only secure system is one that's not powered. That's silly. Sure, airgap your sensitive stuff. But there's a reasonable level of security you can achieve that's far beyond what docker provides, while still retaining a flexible and reasonable computing environment. For example, Xen's xl tool makes making quick and cheap VM containers very simple.
  - lholden 13y ago
    > "the"? Now you are just nitpicking :) "the" meaning, you gave me an example. > If you're executing in kernel mode,.....Grsec/PaX kernel, however. SELinux has a lot of overlap with grsec providing many of the same benefits while being more widely available. The flow of an exploit: 1) entry into a system (app compromise, shell access), 2) inserting/uploading of executable data, 3) execution of said data granting further access (Ex, exploiting a kernel bug, adding a backdoor, manipulating the host system in some way). The goals of Grsec/SELinux, and marking data memory as non execute (NX bit, PaX, Exec Shield) are aimed at preventing #2 and #3. The idea is the prevention of access escalation in the first place. On PaX, the kernel supports utilizing the NX bit on x86-64 and has for quite a while now. Not using a system supporting the NX bit or at least PaX/Exec Shield is pretty stupid. > But there's a reasonable level of security you can achieve that's far beyond what docker provides I had already agreed with you on VMs... no reason to argue this point. :) Since you mention VMs again however, I will also note that VMs are not entirely isolated from the host system. A Xen (as your example) exploit as an example: http://lists.xen.org/archives/html/xen-announce/2012-06/msg00001.html http://lists.xen.org/archives/html/xen-announce/2012-06/msg0...
    - zx2c4 13y ago
      > you gave me an example. Ahh sorry. Well to continue along that example, evidently it breaks out of lots of things -- https://grsecurity.net/~spender/logs.txt https://grsecurity.net/~spender/logs.txt > On PaX, the kernel supports utilizing the NX bit on x86-64 and has for quite a while now. Not using a system supporting the NX bit or at least PaX/Exec Shield is pretty stupid. Not going to try to parse this, but you appear to be very mistaken. Wikipedia PaX. > VMs are not entirely isolated from the host system Correct, hence the parenthetical in the OP. That sysret bug was a great one.
      - lholden 13y ago
        > Not going to try to parse this, but you appear to be very mistaken. Wikipedia PaX. On PaX https://en.wikipedia.org/wiki/PaX#Executable_space_protections https://en.wikipedia.org/wiki/PaX#Executable_space_protectio... "The major feature of PaX is the executable space protection it offers. These protections take advantage of the NX bit on certain processors to prevent the execution of arbitrary code. This staves off attacks involving code injection or shellcode. On IA-32 CPUs where there is no NX bit, PaX can emulate the functionality of one in various ways." And then on NX bit support on Linux: https://en.wikipedia.org/wiki/NX_bit#Linux https://en.wikipedia.org/wiki/NX_bit#Linux "The Linux kernel currently supports the NX bit on x86-64 CPUs and on x86 processors that implement it, such as the current 64-bit CPUs of AMD, Intel, Transmeta and VIA. The support for this feature in the 64-bit mode on x86-64 CPUs was added in 2004 by Andi Kleen, and later the same year, Ingo Molnar added support for it in 32-bit mode on 64-bit CPUs. These features have been in the stable Linux kernel since release 2.6.8 in August 2004." PaX also provides a few other features but the big defining one has been the NX bit support. Not sure why you seem to think I am mistaken in what I said.
shykes 13y ago
The real value of containers is not security (although lxc does include robust security mechanisms), it's the streamlining of application deployment. If you don't trust lxc to sandbox untrusted code, don't! Just deploy 1 production container per VM, or even per physical machine. But maybe you don't mind running multiple containers on your local dev vm or on your staging machine - I know I don't. What containers give you is a constant payload which can be moved across very different hardware setups, from the most shared to the most isolated.
- zx2c4 13y ago
  > it's the streamlining of application deployment. I always liked the idea of nicely integrating with the environment and utilizing the features of package managers, the file system, users, and all the rest of the niceties we have at our disposal. "I don't know how to organize a bunch of things together!" seems like a silly reason to containerize every component into a separate root fs. But on the other hand, I can imagine this work flow does have some merit, and some folks save a lot of time and energy and potential headaches just popping things in containers.
  - shykes 13y ago
    > "I don't know how to organize a bunch of things together!" seems like a silly reason to containerize every component into a separate root fs. One good reason to separate every component is that it facilitates moving them to separate machines down the road, or scaling them separately. Another good reason is that it reduces the out-of-band requirements of the components. "all the niceties" you have at your disposal may very well be specific to your distro, or your site setup. By contrast, docker containers only require docker, which is a single binary file. A developer needs to know his component will run anywhere, not just on your particular setup.
manku_timma 13y ago
Also, In a private PaaS'ish environment, docker's container abstraction is very useful.