Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Process isolation in jails or vservers - added security or unneeded hassle?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Process isolation in jails or vservers - added security or unneeded hassle?

ben78ben78 Member
edited August 2015 in Requests

Hi

I'm setting up a new server for an upcoming project and am considering whether or not I should isolate as much as I can the different processes or if it's not worth the hassle.

Do you consider it's needed or really more secure to isolate as much as possible the processes of a server using BSD jails or linux Vserver (or anything similar)?

Like a jail for web server, another one for db server and a third one for mail server.

If an app get compromised, it sure helps as the attacker would be stuck in a jail or vserver and from there it would be hard or hardly possible to get root on the whole system.

But do you feel like it's needed? Is there better practices that you consider would be better and or more convenient? (system update is a pain with multiple vservers or jails)

Links to external articles and interesting sites are, of course, more than welcome!

Thanks!

Comments

  • I Docker-ize everything.

    Thanked by 1ben78
  • OpenVZ/Docker. Since FreeBSD requires a dedicated server/KVM, you should be able to install OpenVZ and create containers.

    And for a production environment, always isolate and DO NOT start anything as root that doesn't require an effective user ID of 0.

    Thanked by 1ben78
  • ben78ben78 Member
    edited August 2015

    Thanks a lot, didn't know about Docker. Seems great for linux servers - fantastic that it can even run in a low end vps - and a nice way to move services between hosts in case needed.

    Will have to read more about that though, I did just read on a random forum:

    Docker (and LXC for the matter) aren't about security -- they are about portability of the application and environment. Everything else is tertiary.

    Any opinion on that?

  • perennateperennate Member, Host Rep
    edited August 2015

    ben78 said: Any opinion on that?

    https://docs.docker.com/articles/security/

    Security is certainly a design consideration in both LXC and Docker. Of course, virtual machines like KVM/Xen will always offer greater security than containers.

    Edit: and the thing about LXC being about portability more than isolation/security is BS, containers fundamentally are there for isolation; whatever portability there is comes from Docker and other services built on top of the container system

  • perennate said: Of course, virtualization like KVM/Xen will always offer greater security than containers.

    Thanks. I'll probably check LXC with Ansible and Docker to see what fits better.

  • joepie91joepie91 Member, Patron Provider
    edited August 2015

    You should not rely on Docker to give you good security against malicious entities, says a Docker maintainer. Use OpenVZ for that instead, if you need containers.

    Thanked by 1vimalware
  • perennateperennate Member, Host Rep
    edited August 2015

    joepie91 said: You should not rely on Docker to give you good security against malicious entities, says a Docker maintainer. Use OpenVZ for that instead, if you need containers.

    Um, no, that's not at all what he or she is saying. Docker containers provide greater isolation of applications than Linux processes (if configured correctly, which isn't hard). However, the point the maintainer is making is that, if you intend to run untrusted programs as root, then you should use something with much more robust isolation, e.g. a virtual machine or better yet a separate physical server.

    Regardless, preventing escalation from a container is high on the list of concerns of Docker developers. And while it's true that LXC's greater integration with the kernel makes it more prone to security risks, there have nevertheless been many vulnerabilities discovered in OpenVZ.

    As far as I can tell, OP wants to get greater isolation between applications, not run untrusted applications (which you might want e.g. for coding competitions or application hosting). I'm assuming OP is looking for a tradeoff between effort and security, and Docker gives a good tradeoff. Otherwise, OP should go with KVM or Xen.

  • joepie91 said: Use OpenVZ for that instead, if you need containers.

    Thanks for the advice. Do you know how does LXC compare to OpenVZ?

  • perennate said: As far as I can tell, OP wants to get greater isolation between applications, not run untrusted applications (which you might want e.g. for coding competitions or application hosting).

    Exactly, the goal is to isolate applications (web server, db server, etc), not run untrusted code and not move containers around so much. I mean I focus more or maintenance ease than ease to move the container to another provider or machine.

  • perennateperennate Member, Host Rep
    edited August 2015

    ben78 said: Thanks for the advice. Do you know how does LXC compare to OpenVZ?

    OpenVZ may be more secure than LXC because a) LXC has more integration with the kernel and b) OpenVZ been around for a bit longer. However, Docker adds a ton of features on top of LXC that make it much easier to deploy and manage applications on it. And recently there's been much more development focus on LXC.

  • perennate said: Docker adds a ton of features on top of LXC that make it much easier to deploy and manage applications on it. And recently there's been much more development focus on LXC.

    Ok, thanks. Is it easy to keep the applications within a Docker container up to date? (security updates...) did read on some forums that it was kinda complicated...

    I have to experiment with all those solutions to see which one I prefer, but I'd rather gather some information before to know if there are some that have to be avoided..

    Thanks!

  • joepie91joepie91 Member, Patron Provider

    perennate said: Um, no, that's not at all what he or she is saying. Docker containers provide greater isolation of applications than Linux processes (if configured correctly, which isn't hard). However, the point the maintainer is making is that, if you intend to run untrusted programs as root, then you should use something with much more robust isolation, e.g. a virtual machine or better yet a separate physical server.

    It is. Specifically, not good for running untrusted uid0 processes out of the box. That is exactly the kind of thing that OpenVZ does aim to make possible.

    perennate said: there have nevertheless been many vulnerabilities discovered in OpenVZ.

    As is the case for QEMU.

    perennate said: As far as I can tell, OP wants to get greater isolation between applications, not run untrusted applications

    OP spoke of compromised applications. From a security perspective, that means they are untrusted.

    perennate said: and Docker gives a good tradeoff.

    It doesn't. It does not mitigate this threat model.

    ben78 said: Thanks for the advice. Do you know how does LXC compare to OpenVZ?

    I believe the same applies for LXC as for Docker, from what I've read/heard.

    Thanked by 1ben78
  • perennateperennate Member, Host Rep
    edited August 2015

    LXC aims to make running untrusted processes possible as much as OpenVZ does. The point that the maintainer you quoted was making is that virtual machines provide greater isolation and would be preferable; the maintainer was also recommending Docker as an additional layer of security rather than a replacement of process isolation. The maintainer was not saying that the Docker team doesn't care about security, and it's unclear how you inferred it from that comment. Isolating applications for security is pretty much the primary goal of LXC/Docker.

    In fact, unlike OpenVZ/LXC, Docker takes many additional steps to greatly reduce the chance that a vulnerability in the container library can be exploited: kernel capabilities are automatically dropped from containers, AppArmor/SELinux rules are activated by default on distributions of the software, etc.; these additional steps are possible because Docker is implemented at a higher level compared to OpenVZ/LXC, so it knows more about the application and can drop capabilities that the application that will be running in the container doesn't need.

    Furthermore, the vulnerability that you linked to was patched before any exploit was released. The maintainer was merely acknowledging that it would have been possible for there to be a zero-day exploit in 1.0, if things didn't go as well; had this been the case, though, Docker would have obviously released a patch quickly.

    joepie91 said: It doesn't. It does not mitigate this threat model.

    So there was a vulnerability in LXC/Docker that was patched. As a result, now you're claiming that it should never be used to isolate applications (which is the whole point of LXC/Docker). Guess people shouldn't use OpenVZ or QEMU either, since they've also had vulnerabilities in the past.

  • joepie91joepie91 Member, Patron Provider

    perennate said: So there was a vulnerability in LXC/Docker that was patched. As a result, now you're claiming that it should never be used to isolate applications (which is the whole point of LXC/Docker). Guess people shouldn't use OpenVZ or QEMU either, since they've also had vulnerabilities in the past.

    That has absolutely nothing to do with what I said. What I'm saying is that, to my knowledge, this is not currently the intention of either project, nor do they believe it can currently be accomplished. You simply shouldn't be using things for purposes they weren't designed for, where it concerns security.

    LXC and Docker become viable options once they acknowledge that 1) they are intended to provide secure isolation, and 2) the maintainers are of the (informed) opinion that they are capable of doing so. No earlier. OpenVZ reached that stage a while ago.

  • perennateperennate Member, Host Rep
    edited August 2015

    joepie91 said: That has absolutely nothing to do with what I said. What I'm saying is that, to my knowledge, this is not currently the intention of either project, nor do they believe it can currently be accomplished. You simply shouldn't be using things for purposes they weren't designed for, where it concerns security.

    joepie91 said: LXC and Docker become viable options once they acknowledge that 1) they are intended to provide secure isolation, and 2) the maintainers are of the (informed) opinion that they are capable of doing so. No earlier. OpenVZ reached that stage a while ago.

    Now I see what you're arguing. However:

    • Application isolation is a primary goal of both LXC and Docker, and this includes preventing escaping from containers with root privileges in the container; this is why they are working on user namespaces to further improve security; https://blog.docker.com/2013/08/containers-docker-how-secure-are-they/ gives an overview of the approach
    • The design of LXC/Docker kernel namespacing is based on OpenVZ; while OpenVZ developers may claim that their software is suitable for running untrusted applications, the recurring security vulnerabilities make it clear that this is an unsupported claim, and either way LXC implements the same isolation systems that OpenVZ has
    • LXC has Docker, while OpenVZ has nothing similar; Docker is able to implement additional security features because it has knowledge of the application, such as dropping capabilities from the container that the application running inside won't need
Sign In or Register to comment.