5 ms·

I'm quite excited seeing the open source community putting so much work into Linux containers. For the most part they're a lot better than true virtualization.

by susi22 13y ago

I'm quite excited seeing the open source community putting so much work into Linux containers. For the most part they're a lot better than true virtualization. We've seen it in the past, what you guys can do with Puppet as a configuration system. I just wish lxc was as secure as Solaris zones. Since containers are not secure at all, they definitely won't be used for shared hosting. The team seems to be working on it, but it will probably take a few years to get it secure enough: https://wiki.ubuntu.com/LxcSecurity https://wiki.ubuntu.com/LxcSecurity

yebyen 13y ago
> Since containers are not secure at all I feel like you're just spreading FUD here. This was definitely true a few years ago, but "Citation Needed" applies. The worst thing I found in the article you linked is that guests use the same kernel as the host, so if the host kernel is vulnerable, it will still be vulnerable from the guest... Then it goes on to say "we have seccomp2 to lower the dimensions of attack surface." It does not sound to me like your citation agrees with what you said at all. I just hope you've read the top-rated comment, where it's explained that containers are not virtualization, and they solve different problems.
- susi22 13y ago
  IF you have root on the container, you have root on the host. This is a HUGE difference and probably one of the main reasons LXC isn't in huge use for VPS. This is, btw, different than Solaris Zones, which give you a complete new user management for each container. They're very isolated. Zones have had some exploits to get out of the Zone, but they're pretty secure. LXC has started moving towards a more secure design but it will take years (IMO) to get LXC actually in production for _shared_ hosting. See: https://www.suse.com/documentation/sles11/singlehtml/lxc_quickstart/lxc_quickstart.html https://www.suse.com/documentation/sles11/singlehtml/lxc_qui... Security depends on the host system. LXC is not secure. If you need a secure system, use KVM. http://www.funtoo.org/Linux_Containers http://www.funtoo.org/Linux_Containers As of Linux kernel 3.1.5, LXC is usable for isolating your own private workloads from one another. It is not yet ready to isolate potentially malicious users from one another or the host system. For a more mature containers solution that is appropriate for hosting environments, see OpenVZ. http://lwn.net/Articles/515034/ http://lwn.net/Articles/515034/ "Containers are not for security", he said, because root inside the container can always escape, so the container gets wrapped in SELinux to restrict it ... A number of steps have been taken to try to prevent root from breaking out of the container, but there is more to be done. Both mount and mknod will fail inside the container for example. These containers are not as secure as full virtualization, Walsh said, but they are much easier to manage than handling the multiple full operating systems that virtualization requires. For many use cases, secure containers may be the right fit.
  - pekk 13y ago
    As I understand, bulletproof isolation between mutually untrusting users on a shared system was never the point of Docker. And, if security is very important to you, why are you deploying to a machine shared with people you don't trust?
  - jpetazzo 13y ago
    Sorry, but this is FUD: > IF you have root on the container, you have root on the host. This is only true on badly configured systems. If you run some kind of public shared hosting (like Heroku, dotCloud, etc.) you probably slap some extra security on top of it. For instance, dotCloud uses GRSEC, limits root access, and uses kernel capabilities. It won't take years to get LXC in production for shared hosting: it has been in production for shared hosting for years -- but by people who (more or less) knew what they were doing. Agreed, "out-of-the-box LXC" is probably not that secure; which is probably why many people won't deploy it. And I can't blame them. Any technology generally starts being usable (or usable safely) only for expert users, then progressively gets more industrialized and ready to use for a broader audience. It doesn't mean that the technology is not mature. Also, the user separation that you mention has been implemented in the Linux kernel for a while[1]; it's called "user namespace", and even if the default LXC userland tools do not make use of it at this point, it's here. [1] https://wiki.ubuntu.com/UserNamespace https://wiki.ubuntu.com/UserNamespace
    - susi22 13y ago
      I do know those things. It doesn't change the fact that you can _easily_ break out of a Container and compromise neighboring Containers. No matter how much to harden the system you implement. Who is using LXC in a _shared_ hosting environment?
  - yebyen 13y ago
    You've cited kernel 3.1.5 which was literally a couple of years ago. As for the rest of your resources, they are LXC without Docker. Docker is the special sauce that makes MongoDB WebScale. No really... if Containers are not for security, Namespaces and CGroups are. I won't pretend to know what SElinux does, or exactly how all of this works, docker does not purport to be production ready, but I would think that sharing the box with someone else would be the fastest way to find out if it can be broken. (Upvote for at least showing some good research.)

by susi22 13y ago

yebyen 13y ago

> Since containers are not secure at all I feel like you're just spreading FUD here. This was definitely true a few years ago, but "Citation Needed" applies. The worst thing I found in the article you linked is that guests use the same kernel as the host, so if the host kernel is vulnerable, it will still be vulnerable from the guest... Then it goes on to say "we have seccomp2 to lower the dimensions of attack surface." It does not sound to me like your citation agrees with what you said at all. I just hope you've read the top-rated comment, where it's explained that containers are not virtualization, and they solve different problems.

susi22 13y ago
IF you have root on the container, you have root on the host. This is a HUGE difference and probably one of the main reasons LXC isn't in huge use for VPS. This is, btw, different than Solaris Zones, which give you a complete new user management for each container. They're very isolated. Zones have had some exploits to get out of the Zone, but they're pretty secure. LXC has started moving towards a more secure design but it will take years (IMO) to get LXC actually in production for _shared_ hosting. See: https://www.suse.com/documentation/sles11/singlehtml/lxc_quickstart/lxc_quickstart.html https://www.suse.com/documentation/sles11/singlehtml/lxc_qui... Security depends on the host system. LXC is not secure. If you need a secure system, use KVM. http://www.funtoo.org/Linux_Containers http://www.funtoo.org/Linux_Containers As of Linux kernel 3.1.5, LXC is usable for isolating your own private workloads from one another. It is not yet ready to isolate potentially malicious users from one another or the host system. For a more mature containers solution that is appropriate for hosting environments, see OpenVZ. http://lwn.net/Articles/515034/ http://lwn.net/Articles/515034/ "Containers are not for security", he said, because root inside the container can always escape, so the container gets wrapped in SELinux to restrict it ... A number of steps have been taken to try to prevent root from breaking out of the container, but there is more to be done. Both mount and mknod will fail inside the container for example. These containers are not as secure as full virtualization, Walsh said, but they are much easier to manage than handling the multiple full operating systems that virtualization requires. For many use cases, secure containers may be the right fit.
- pekk 13y ago
  As I understand, bulletproof isolation between mutually untrusting users on a shared system was never the point of Docker. And, if security is very important to you, why are you deploying to a machine shared with people you don't trust?
- jpetazzo 13y ago
  Sorry, but this is FUD: > IF you have root on the container, you have root on the host. This is only true on badly configured systems. If you run some kind of public shared hosting (like Heroku, dotCloud, etc.) you probably slap some extra security on top of it. For instance, dotCloud uses GRSEC, limits root access, and uses kernel capabilities. It won't take years to get LXC in production for shared hosting: it has been in production for shared hosting for years -- but by people who (more or less) knew what they were doing. Agreed, "out-of-the-box LXC" is probably not that secure; which is probably why many people won't deploy it. And I can't blame them. Any technology generally starts being usable (or usable safely) only for expert users, then progressively gets more industrialized and ready to use for a broader audience. It doesn't mean that the technology is not mature. Also, the user separation that you mention has been implemented in the Linux kernel for a while[1]; it's called "user namespace", and even if the default LXC userland tools do not make use of it at this point, it's here. [1] https://wiki.ubuntu.com/UserNamespace https://wiki.ubuntu.com/UserNamespace
  - susi22 13y ago
    I do know those things. It doesn't change the fact that you can _easily_ break out of a Container and compromise neighboring Containers. No matter how much to harden the system you implement. Who is using LXC in a _shared_ hosting environment?
- yebyen 13y ago
  You've cited kernel 3.1.5 which was literally a couple of years ago. As for the rest of your resources, they are LXC without Docker. Docker is the special sauce that makes MongoDB WebScale. No really... if Containers are not for security, Namespaces and CGroups are. I won't pretend to know what SElinux does, or exactly how all of this works, docker does not purport to be production ready, but I would think that sharing the box with someone else would be the fastest way to find out if it can be broken. (Upvote for at least showing some good research.)