4 ms·

Yes, the security is there. Though, resource fairness is not (since you have basically bare metal access). SmartOS is trying to fix this: http://wiki.smartos.o

by susi22 13y ago

Yes, the security is there. Though, resource fairness is not (since you have basically bare metal access). SmartOS is trying to fix this: http://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle http://wiki.smartos.org/display/DOC/Tuning+the+IO+Throttle http://dtrace.org/blogs/brendan/2012/12/19/the-use-method-smartos-performance-checklist/ http://dtrace.org/blogs/brendan/2012/12/19/the-use-method-sm...

wmf 13y ago
Linux now has fair sharing for CPU, disk, and network if you can figure out how to configure it. Or you can use cgroups to guarantee resources to make containers act more like VMs.
- davidstrauss 13y ago
  cgroups are the method of doing fair resource sharing.
Estragon 13y ago
How can the security be comparable? I would have thought that the kernel shared between containerized processes presents a much bigger attack surface than a virtual machine monitor does.
chubot 13y ago
That's not true -- Linux has had local root exploits pretty much at ALL times. If you're in a container, you can break out with one of these exploits. You'll be root and have access to all other containers on the machine. In a VM, you don't share a kernel with other users, so the local root exploit doesn't buy you anything. I prefer containers and think VMs are a huge hack for most problems. But as it stands now, the number of local root exploits vs say remote exploits on Linux is probably greater by a factor of 100 or so, so you're taking much more risk. Security is one of the problems with Linux containers that still needs to be resolved. (see http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/ http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/, Google "lxc security")
- darkarmani 13y ago
  > I prefer containers and think VMs are a huge hack for most problems. But as it stands now, the number of local root exploits vs say remote exploits on Linux is probably greater by a factor of 100 or so, so you're taking much more risk. Yeah, but if you can run services in containers that don't need root access, you know have to exploit the services, find a privilege escalation exploit, and then run your local root exploit. If you don't give out root access in your containers, you can get the advantages of containers while minimizing the downsides.
  - chubot 13y ago
    In the context of PaaS, you just upload the local root exploit and run it. There's no need to exploit any services -- it's one step. The local root exploit is the privilege escalation.
    - darkarmani 13y ago
      I'm not sure why you say that. You can have root inside a container and still not break out of it. You need an exploit that breaks you out of the container.
- davidstrauss 13y ago
  > That's not true -- Linux has had local root exploits pretty much at ALL times. If you're in a container, you can break out with one of these exploits. You'll be root and have access to all other containers on the machine. Isolation strategies involving syscall filtering and mandatory access control (MAC) tools like selinux dramatically reduce the attack surface. For example, I know several recent root exploits were not possible to run on Fedora with selinux enabled. People also discover hypervisor exploits at a reliable clip, too. Virtualization isn't a panacea of security isolation.
  - chubot 13y ago
    Well that is what I hoped the article would cover in more detail :) That is, what actually works out of the box with LXC and what doesn't. As of 6-12 months ago I don't think the LXC on any distro was particularly secure. AFAIK you have to add SELinux yourself, and all the PaaS providers are probably doing something custom (or not). The newer thing seems to be seccomp filters (http://lwn.net/Articles/494252/ http://lwn.net/Articles/494252/), which are motivated by ChromeOS. I would like to see a comparison; from what I can tell seccomp is a lot simpler conceptually, although there are fewer user space tools for it. The article didn't actually say "LXC" but it seems to be what most PaaS providers are using. When I tried LXC, while lighter than VMs, it also seemed too heavy, because you end up with 5 or 6 processes (starting with an "init") for every process you want to run. Using just raw namespaces and cgroups seems to be feasible although again there are few tools to do that. Apparently systemd has support, although I don't use any distros with it. Docker is also a new thing, but I think it is just on top of LXC, so it is only as secure as your distro's LXC is.

by susi22 13y ago

wmf 13y ago

Linux now has fair sharing for CPU, disk, and network if you can figure out how to configure it. Or you can use cgroups to guarantee resources to make containers act more like VMs.

davidstrauss 13y ago
cgroups are the method of doing fair resource sharing.

Estragon 13y ago

How can the security be comparable? I would have thought that the kernel shared between containerized processes presents a much bigger attack surface than a virtual machine monitor does.

chubot 13y ago

That's not true -- Linux has had local root exploits pretty much at ALL times. If you're in a container, you can break out with one of these exploits. You'll be root and have access to all other containers on the machine. In a VM, you don't share a kernel with other users, so the local root exploit doesn't buy you anything. I prefer containers and think VMs are a huge hack for most problems. But as it stands now, the number of local root exploits vs say remote exploits on Linux is probably greater by a factor of 100 or so, so you're taking much more risk. Security is one of the problems with Linux containers that still needs to be resolved. (see http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/ http://mattoncloud.org/2012/07/16/are-lxc-containers-enough/, Google "lxc security")

darkarmani 13y ago
> I prefer containers and think VMs are a huge hack for most problems. But as it stands now, the number of local root exploits vs say remote exploits on Linux is probably greater by a factor of 100 or so, so you're taking much more risk. Yeah, but if you can run services in containers that don't need root access, you know have to exploit the services, find a privilege escalation exploit, and then run your local root exploit. If you don't give out root access in your containers, you can get the advantages of containers while minimizing the downsides.
- chubot 13y ago
  In the context of PaaS, you just upload the local root exploit and run it. There's no need to exploit any services -- it's one step. The local root exploit is the privilege escalation.
  - darkarmani 13y ago
    I'm not sure why you say that. You can have root inside a container and still not break out of it. You need an exploit that breaks you out of the container.
davidstrauss 13y ago
> That's not true -- Linux has had local root exploits pretty much at ALL times. If you're in a container, you can break out with one of these exploits. You'll be root and have access to all other containers on the machine. Isolation strategies involving syscall filtering and mandatory access control (MAC) tools like selinux dramatically reduce the attack surface. For example, I know several recent root exploits were not possible to run on Fedora with selinux enabled. People also discover hypervisor exploits at a reliable clip, too. Virtualization isn't a panacea of security isolation.
- chubot 13y ago
  Well that is what I hoped the article would cover in more detail :) That is, what actually works out of the box with LXC and what doesn't. As of 6-12 months ago I don't think the LXC on any distro was particularly secure. AFAIK you have to add SELinux yourself, and all the PaaS providers are probably doing something custom (or not). The newer thing seems to be seccomp filters (http://lwn.net/Articles/494252/ http://lwn.net/Articles/494252/), which are motivated by ChromeOS. I would like to see a comparison; from what I can tell seccomp is a lot simpler conceptually, although there are fewer user space tools for it. The article didn't actually say "LXC" but it seems to be what most PaaS providers are using. When I tried LXC, while lighter than VMs, it also seemed too heavy, because you end up with 5 or 6 processes (starting with an "init") for every process you want to run. Using just raw namespaces and cgroups seems to be feasible although again there are few tools to do that. Apparently systemd has support, although I don't use any distros with it. Docker is also a new thing, but I think it is just on top of LXC, so it is only as secure as your distro's LXC is.