Linux LXC vs FreeBSD jail

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












58














Are there any notable differences between LXC (Linux containers) and FreeBSD's jails in terms of security, stability & performance?



On first look, both approaches look very similar.










share|improve this question



















  • 1




    LXC is a rather new technology, so I would expect better security and stability with jails. Not even a guess about performance. There are some known security issues with LXC that can be mitigated using selinux, for example. I personally like LXC, though.
    – Pavel Šimerda
    Apr 28 '14 at 23:30






  • 1




    @PavelŠimerda I just heard of LXC today, but I was suprised to find outh that both Heroku and probably Google App Engine already use LXC.
    – Philipp Claßen
    Apr 29 '14 at 0:01






  • 3




    If you've just bumped into LXC you should take a look at Docker which uses LXC under the bonnet: docker.io/the_whole_story
    – Kev
    Apr 29 '14 at 0:54






  • 1




    Docker does not uses lxc anymore.
    – nwildner
    Jan 24 '16 at 13:33






  • 1




    @nwildner it doesn't use liblxc anymore, but it uses the exact same concepts: kernel namespaces.
    – 0xC0000022L
    May 3 at 14:39















58














Are there any notable differences between LXC (Linux containers) and FreeBSD's jails in terms of security, stability & performance?



On first look, both approaches look very similar.










share|improve this question



















  • 1




    LXC is a rather new technology, so I would expect better security and stability with jails. Not even a guess about performance. There are some known security issues with LXC that can be mitigated using selinux, for example. I personally like LXC, though.
    – Pavel Šimerda
    Apr 28 '14 at 23:30






  • 1




    @PavelŠimerda I just heard of LXC today, but I was suprised to find outh that both Heroku and probably Google App Engine already use LXC.
    – Philipp Claßen
    Apr 29 '14 at 0:01






  • 3




    If you've just bumped into LXC you should take a look at Docker which uses LXC under the bonnet: docker.io/the_whole_story
    – Kev
    Apr 29 '14 at 0:54






  • 1




    Docker does not uses lxc anymore.
    – nwildner
    Jan 24 '16 at 13:33






  • 1




    @nwildner it doesn't use liblxc anymore, but it uses the exact same concepts: kernel namespaces.
    – 0xC0000022L
    May 3 at 14:39













58












58








58


31





Are there any notable differences between LXC (Linux containers) and FreeBSD's jails in terms of security, stability & performance?



On first look, both approaches look very similar.










share|improve this question















Are there any notable differences between LXC (Linux containers) and FreeBSD's jails in terms of security, stability & performance?



On first look, both approaches look very similar.







linux freebsd virtualization lxc jails






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 29 '14 at 1:42









slm

246k66507673




246k66507673










asked Apr 28 '14 at 23:21









Philipp Claßen

1,35531831




1,35531831







  • 1




    LXC is a rather new technology, so I would expect better security and stability with jails. Not even a guess about performance. There are some known security issues with LXC that can be mitigated using selinux, for example. I personally like LXC, though.
    – Pavel Šimerda
    Apr 28 '14 at 23:30






  • 1




    @PavelŠimerda I just heard of LXC today, but I was suprised to find outh that both Heroku and probably Google App Engine already use LXC.
    – Philipp Claßen
    Apr 29 '14 at 0:01






  • 3




    If you've just bumped into LXC you should take a look at Docker which uses LXC under the bonnet: docker.io/the_whole_story
    – Kev
    Apr 29 '14 at 0:54






  • 1




    Docker does not uses lxc anymore.
    – nwildner
    Jan 24 '16 at 13:33






  • 1




    @nwildner it doesn't use liblxc anymore, but it uses the exact same concepts: kernel namespaces.
    – 0xC0000022L
    May 3 at 14:39












  • 1




    LXC is a rather new technology, so I would expect better security and stability with jails. Not even a guess about performance. There are some known security issues with LXC that can be mitigated using selinux, for example. I personally like LXC, though.
    – Pavel Šimerda
    Apr 28 '14 at 23:30






  • 1




    @PavelŠimerda I just heard of LXC today, but I was suprised to find outh that both Heroku and probably Google App Engine already use LXC.
    – Philipp Claßen
    Apr 29 '14 at 0:01






  • 3




    If you've just bumped into LXC you should take a look at Docker which uses LXC under the bonnet: docker.io/the_whole_story
    – Kev
    Apr 29 '14 at 0:54






  • 1




    Docker does not uses lxc anymore.
    – nwildner
    Jan 24 '16 at 13:33






  • 1




    @nwildner it doesn't use liblxc anymore, but it uses the exact same concepts: kernel namespaces.
    – 0xC0000022L
    May 3 at 14:39







1




1




LXC is a rather new technology, so I would expect better security and stability with jails. Not even a guess about performance. There are some known security issues with LXC that can be mitigated using selinux, for example. I personally like LXC, though.
– Pavel Šimerda
Apr 28 '14 at 23:30




LXC is a rather new technology, so I would expect better security and stability with jails. Not even a guess about performance. There are some known security issues with LXC that can be mitigated using selinux, for example. I personally like LXC, though.
– Pavel Šimerda
Apr 28 '14 at 23:30




1




1




@PavelŠimerda I just heard of LXC today, but I was suprised to find outh that both Heroku and probably Google App Engine already use LXC.
– Philipp Claßen
Apr 29 '14 at 0:01




@PavelŠimerda I just heard of LXC today, but I was suprised to find outh that both Heroku and probably Google App Engine already use LXC.
– Philipp Claßen
Apr 29 '14 at 0:01




3




3




If you've just bumped into LXC you should take a look at Docker which uses LXC under the bonnet: docker.io/the_whole_story
– Kev
Apr 29 '14 at 0:54




If you've just bumped into LXC you should take a look at Docker which uses LXC under the bonnet: docker.io/the_whole_story
– Kev
Apr 29 '14 at 0:54




1




1




Docker does not uses lxc anymore.
– nwildner
Jan 24 '16 at 13:33




Docker does not uses lxc anymore.
– nwildner
Jan 24 '16 at 13:33




1




1




@nwildner it doesn't use liblxc anymore, but it uses the exact same concepts: kernel namespaces.
– 0xC0000022L
May 3 at 14:39




@nwildner it doesn't use liblxc anymore, but it uses the exact same concepts: kernel namespaces.
– 0xC0000022L
May 3 at 14:39










1 Answer
1






active

oldest

votes


















97














No matter the fancy name used here, both are solutions to a specific problem: A better segregation solution than classic Unix chroot. Operating system-level virtualization, containers, zones, or even "chroot with steroids" are names or commercial titles that define the same concept of userspace separation, but with different features.



Chroot was introduced on 18 March 1982, months before the release of 4.2 BSD, as a tool to test its installation and build system, but today it still has its flaws. Since the first objective of chroot was only to provide a newroot path, other aspects of system that needed to be isolated or controlled got uncovered (network, process view, I/O throughput). This is where the first containers (User-level virtualization) appeared.



Both technologies (FreeBSD Jails and LXC) make use of userspace isolation to provide another layer of security. This compartmentalization will ensure that a determined process will communicate only with other processes in the same container on the same host, and if using any network resource to achieve "outside world" communication, all will be forwarded to the assigned interface/channel that this container has.



Features



FreeBSD Jails:



  • Considered stable technology, since it is a feature inside FreeBSD since 4.0;

  • It takes the best of ZFS filesystem at the point where you could clone jails and create jail templates to easily deploy more jails. Some more ZFS madness;


  • Well documented, and evolving;

  • Hierarchical Jails allow you to create jails inside a jail (we need to go deeper!). Combine with allow.mount.zfs to achieve more power, and other variables like children.max do define max children jails.


  • rctl(8) will handle resource limits of jails (memory, CPU, disk, ...);

  • FreeBSD jails handle Linux userspace;

  • Network isolation with vnet, allowing each jail to have its own network stack, interfaces, addressing and routing tables;


  • nullfs to help linking folders to ones that are located on the real server to inside a jail;


  • ezjail utility to help mass deployments and management of jails;

  • Lots of kernel tunables (sysctl). security.jail.allow.* parameters will limit the actions of the root user of that jail.

  • Maybe, FreeBSD jails will extend some of the VPS project features like live migration in a near future.

  • There is some effort of ZFS and Docker integration running. Still experimental.


  • FreeBSD 12 supports bhyve inside a jail and pf inside a jail, creating further isolation to those tools

  • Lots of interesting tools were developed during the last years. Some of them are indexed on this blog post.


  • Alternatives: FreeBSD VPS project

Linux Containers (LXC):



  • New "in kernel" technology but being endorsed by big ones(specially Canonical);


  • Unprivileged containers starting from LXC 1.0, makes a big step into security inside containers;

  • UID and GID mapping inside containers;

  • Kernel namespaces, to make separation of IPC, mount, pid, network and users. These namespaces can be handled in a detached way, where a process that uses a different network namespace will not necessarily be isolated on other aspects like storage;

  • Control Groups (cgroups) to manage resources and grouping them. CGManager is the guy to achieve that.

  • Apparmor/SELinux profiles and Kernel capabilities for better enforcing Kernel features accessible by containers. Seccomp is also available on lxc containers to filter system calls. Other security aspects here.


  • Live migration functionality being developed. It’s really hard to say when it will be ready for production use, since docker/lxc will have to deal with userspace process pause, snapshot, migrate and consolidate - ref1, ref2. Live migration is working with basic containers(no device passthrough neither complex network services or special storage configurations).

  • APIs bindings to enable development in python3 and 2, lua, Go, Ruby and Haskell

  • Centralized "What's new" area. Pretty useful whenever you need to check if some bug was fixed or a new feature got committed. Here.

  • An interesting alternative could be lxd, that under the hood works with lxc but, it has some nice features like a REST api, OpenStack integration, etc.

  • Another interesting thing is that Ubuntu seems to be shipping zfs as the default filesystem for containers on 16.04. To keep projects aligned, lxd launched it's 2.0 version, and some of the features are zfs related.


  • Alternatives: OpenVZ, Docker


  • Docker. Note here that Docker uses namespaces, cgroups creating "per app"/"per software" isolation. Key differences here. While LXC creates containers with multiple processes, Docker reduces a container as much as possible to a single process and then manage that through Docker.

  • Effort on integrating Docker with SELinux and reducing capabilities inside a container to make it more secure - Docker and SELinux, Dan Walsh

  • What is the difference between Docker, LXD, and LXC

Docker no longer uses lxc. They now have a specific lib called libcontainer that handles the integration with low-level Kernel namespace and cgroups features directly.



Neither technology is a security panacea, but both are pretty good ways to isolate an environment that doesn’t require Full Virtualization due to mixed operating systems infrastructure. Security will come after a lot of documentation reading and implementation of kernel tunables, MAC and isolations that those OS-Level virt offer to you.



See Also:



  • Hand-crafted containers

  • BSD Now: Everything you need to know about Jails

  • ezjail – Jail administration framework

  • A Brief History of Containers: From the 1970s to 2017


  • Docker Considered Harmful - Good article about the security circus around container technologies.





share|improve this answer


















  • 1




    Worth mentioning that out of the box, there is no effort by lxc to provide proper guest isolation. lxd, however, does attempt to provide isolation like BSD jails or Solaris zones.
    – allquixotic
    Jun 23 '15 at 14:06










  • lxd is a "better experience" of LXC, putting other features on top of it. However, it seems nice to quote this little guy in here
    – nwildner
    Sep 21 '15 at 12:22










  • @allquixotic you mean if using unchanged configuration created from templates? True, but unprivileged (userns-enabled) containers were available with LXC 1.x and could even be auto-started at system boot, provided that they were owned by root (and thus located in the system-wide location for containers).
    – 0xC0000022L
    May 3 at 14:47










Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f127001%2flinux-lxc-vs-freebsd-jail%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









97














No matter the fancy name used here, both are solutions to a specific problem: A better segregation solution than classic Unix chroot. Operating system-level virtualization, containers, zones, or even "chroot with steroids" are names or commercial titles that define the same concept of userspace separation, but with different features.



Chroot was introduced on 18 March 1982, months before the release of 4.2 BSD, as a tool to test its installation and build system, but today it still has its flaws. Since the first objective of chroot was only to provide a newroot path, other aspects of system that needed to be isolated or controlled got uncovered (network, process view, I/O throughput). This is where the first containers (User-level virtualization) appeared.



Both technologies (FreeBSD Jails and LXC) make use of userspace isolation to provide another layer of security. This compartmentalization will ensure that a determined process will communicate only with other processes in the same container on the same host, and if using any network resource to achieve "outside world" communication, all will be forwarded to the assigned interface/channel that this container has.



Features



FreeBSD Jails:



  • Considered stable technology, since it is a feature inside FreeBSD since 4.0;

  • It takes the best of ZFS filesystem at the point where you could clone jails and create jail templates to easily deploy more jails. Some more ZFS madness;


  • Well documented, and evolving;

  • Hierarchical Jails allow you to create jails inside a jail (we need to go deeper!). Combine with allow.mount.zfs to achieve more power, and other variables like children.max do define max children jails.


  • rctl(8) will handle resource limits of jails (memory, CPU, disk, ...);

  • FreeBSD jails handle Linux userspace;

  • Network isolation with vnet, allowing each jail to have its own network stack, interfaces, addressing and routing tables;


  • nullfs to help linking folders to ones that are located on the real server to inside a jail;


  • ezjail utility to help mass deployments and management of jails;

  • Lots of kernel tunables (sysctl). security.jail.allow.* parameters will limit the actions of the root user of that jail.

  • Maybe, FreeBSD jails will extend some of the VPS project features like live migration in a near future.

  • There is some effort of ZFS and Docker integration running. Still experimental.


  • FreeBSD 12 supports bhyve inside a jail and pf inside a jail, creating further isolation to those tools

  • Lots of interesting tools were developed during the last years. Some of them are indexed on this blog post.


  • Alternatives: FreeBSD VPS project

Linux Containers (LXC):



  • New "in kernel" technology but being endorsed by big ones(specially Canonical);


  • Unprivileged containers starting from LXC 1.0, makes a big step into security inside containers;

  • UID and GID mapping inside containers;

  • Kernel namespaces, to make separation of IPC, mount, pid, network and users. These namespaces can be handled in a detached way, where a process that uses a different network namespace will not necessarily be isolated on other aspects like storage;

  • Control Groups (cgroups) to manage resources and grouping them. CGManager is the guy to achieve that.

  • Apparmor/SELinux profiles and Kernel capabilities for better enforcing Kernel features accessible by containers. Seccomp is also available on lxc containers to filter system calls. Other security aspects here.


  • Live migration functionality being developed. It’s really hard to say when it will be ready for production use, since docker/lxc will have to deal with userspace process pause, snapshot, migrate and consolidate - ref1, ref2. Live migration is working with basic containers(no device passthrough neither complex network services or special storage configurations).

  • APIs bindings to enable development in python3 and 2, lua, Go, Ruby and Haskell

  • Centralized "What's new" area. Pretty useful whenever you need to check if some bug was fixed or a new feature got committed. Here.

  • An interesting alternative could be lxd, that under the hood works with lxc but, it has some nice features like a REST api, OpenStack integration, etc.

  • Another interesting thing is that Ubuntu seems to be shipping zfs as the default filesystem for containers on 16.04. To keep projects aligned, lxd launched it's 2.0 version, and some of the features are zfs related.


  • Alternatives: OpenVZ, Docker


  • Docker. Note here that Docker uses namespaces, cgroups creating "per app"/"per software" isolation. Key differences here. While LXC creates containers with multiple processes, Docker reduces a container as much as possible to a single process and then manage that through Docker.

  • Effort on integrating Docker with SELinux and reducing capabilities inside a container to make it more secure - Docker and SELinux, Dan Walsh

  • What is the difference between Docker, LXD, and LXC

Docker no longer uses lxc. They now have a specific lib called libcontainer that handles the integration with low-level Kernel namespace and cgroups features directly.



Neither technology is a security panacea, but both are pretty good ways to isolate an environment that doesn’t require Full Virtualization due to mixed operating systems infrastructure. Security will come after a lot of documentation reading and implementation of kernel tunables, MAC and isolations that those OS-Level virt offer to you.



See Also:



  • Hand-crafted containers

  • BSD Now: Everything you need to know about Jails

  • ezjail – Jail administration framework

  • A Brief History of Containers: From the 1970s to 2017


  • Docker Considered Harmful - Good article about the security circus around container technologies.





share|improve this answer


















  • 1




    Worth mentioning that out of the box, there is no effort by lxc to provide proper guest isolation. lxd, however, does attempt to provide isolation like BSD jails or Solaris zones.
    – allquixotic
    Jun 23 '15 at 14:06










  • lxd is a "better experience" of LXC, putting other features on top of it. However, it seems nice to quote this little guy in here
    – nwildner
    Sep 21 '15 at 12:22










  • @allquixotic you mean if using unchanged configuration created from templates? True, but unprivileged (userns-enabled) containers were available with LXC 1.x and could even be auto-started at system boot, provided that they were owned by root (and thus located in the system-wide location for containers).
    – 0xC0000022L
    May 3 at 14:47















97














No matter the fancy name used here, both are solutions to a specific problem: A better segregation solution than classic Unix chroot. Operating system-level virtualization, containers, zones, or even "chroot with steroids" are names or commercial titles that define the same concept of userspace separation, but with different features.



Chroot was introduced on 18 March 1982, months before the release of 4.2 BSD, as a tool to test its installation and build system, but today it still has its flaws. Since the first objective of chroot was only to provide a newroot path, other aspects of system that needed to be isolated or controlled got uncovered (network, process view, I/O throughput). This is where the first containers (User-level virtualization) appeared.



Both technologies (FreeBSD Jails and LXC) make use of userspace isolation to provide another layer of security. This compartmentalization will ensure that a determined process will communicate only with other processes in the same container on the same host, and if using any network resource to achieve "outside world" communication, all will be forwarded to the assigned interface/channel that this container has.



Features



FreeBSD Jails:



  • Considered stable technology, since it is a feature inside FreeBSD since 4.0;

  • It takes the best of ZFS filesystem at the point where you could clone jails and create jail templates to easily deploy more jails. Some more ZFS madness;


  • Well documented, and evolving;

  • Hierarchical Jails allow you to create jails inside a jail (we need to go deeper!). Combine with allow.mount.zfs to achieve more power, and other variables like children.max do define max children jails.


  • rctl(8) will handle resource limits of jails (memory, CPU, disk, ...);

  • FreeBSD jails handle Linux userspace;

  • Network isolation with vnet, allowing each jail to have its own network stack, interfaces, addressing and routing tables;


  • nullfs to help linking folders to ones that are located on the real server to inside a jail;


  • ezjail utility to help mass deployments and management of jails;

  • Lots of kernel tunables (sysctl). security.jail.allow.* parameters will limit the actions of the root user of that jail.

  • Maybe, FreeBSD jails will extend some of the VPS project features like live migration in a near future.

  • There is some effort of ZFS and Docker integration running. Still experimental.


  • FreeBSD 12 supports bhyve inside a jail and pf inside a jail, creating further isolation to those tools

  • Lots of interesting tools were developed during the last years. Some of them are indexed on this blog post.


  • Alternatives: FreeBSD VPS project

Linux Containers (LXC):



  • New "in kernel" technology but being endorsed by big ones(specially Canonical);


  • Unprivileged containers starting from LXC 1.0, makes a big step into security inside containers;

  • UID and GID mapping inside containers;

  • Kernel namespaces, to make separation of IPC, mount, pid, network and users. These namespaces can be handled in a detached way, where a process that uses a different network namespace will not necessarily be isolated on other aspects like storage;

  • Control Groups (cgroups) to manage resources and grouping them. CGManager is the guy to achieve that.

  • Apparmor/SELinux profiles and Kernel capabilities for better enforcing Kernel features accessible by containers. Seccomp is also available on lxc containers to filter system calls. Other security aspects here.


  • Live migration functionality being developed. It’s really hard to say when it will be ready for production use, since docker/lxc will have to deal with userspace process pause, snapshot, migrate and consolidate - ref1, ref2. Live migration is working with basic containers(no device passthrough neither complex network services or special storage configurations).

  • APIs bindings to enable development in python3 and 2, lua, Go, Ruby and Haskell

  • Centralized "What's new" area. Pretty useful whenever you need to check if some bug was fixed or a new feature got committed. Here.

  • An interesting alternative could be lxd, that under the hood works with lxc but, it has some nice features like a REST api, OpenStack integration, etc.

  • Another interesting thing is that Ubuntu seems to be shipping zfs as the default filesystem for containers on 16.04. To keep projects aligned, lxd launched it's 2.0 version, and some of the features are zfs related.


  • Alternatives: OpenVZ, Docker


  • Docker. Note here that Docker uses namespaces, cgroups creating "per app"/"per software" isolation. Key differences here. While LXC creates containers with multiple processes, Docker reduces a container as much as possible to a single process and then manage that through Docker.

  • Effort on integrating Docker with SELinux and reducing capabilities inside a container to make it more secure - Docker and SELinux, Dan Walsh

  • What is the difference between Docker, LXD, and LXC

Docker no longer uses lxc. They now have a specific lib called libcontainer that handles the integration with low-level Kernel namespace and cgroups features directly.



Neither technology is a security panacea, but both are pretty good ways to isolate an environment that doesn’t require Full Virtualization due to mixed operating systems infrastructure. Security will come after a lot of documentation reading and implementation of kernel tunables, MAC and isolations that those OS-Level virt offer to you.



See Also:



  • Hand-crafted containers

  • BSD Now: Everything you need to know about Jails

  • ezjail – Jail administration framework

  • A Brief History of Containers: From the 1970s to 2017


  • Docker Considered Harmful - Good article about the security circus around container technologies.





share|improve this answer


















  • 1




    Worth mentioning that out of the box, there is no effort by lxc to provide proper guest isolation. lxd, however, does attempt to provide isolation like BSD jails or Solaris zones.
    – allquixotic
    Jun 23 '15 at 14:06










  • lxd is a "better experience" of LXC, putting other features on top of it. However, it seems nice to quote this little guy in here
    – nwildner
    Sep 21 '15 at 12:22










  • @allquixotic you mean if using unchanged configuration created from templates? True, but unprivileged (userns-enabled) containers were available with LXC 1.x and could even be auto-started at system boot, provided that they were owned by root (and thus located in the system-wide location for containers).
    – 0xC0000022L
    May 3 at 14:47













97












97








97






No matter the fancy name used here, both are solutions to a specific problem: A better segregation solution than classic Unix chroot. Operating system-level virtualization, containers, zones, or even "chroot with steroids" are names or commercial titles that define the same concept of userspace separation, but with different features.



Chroot was introduced on 18 March 1982, months before the release of 4.2 BSD, as a tool to test its installation and build system, but today it still has its flaws. Since the first objective of chroot was only to provide a newroot path, other aspects of system that needed to be isolated or controlled got uncovered (network, process view, I/O throughput). This is where the first containers (User-level virtualization) appeared.



Both technologies (FreeBSD Jails and LXC) make use of userspace isolation to provide another layer of security. This compartmentalization will ensure that a determined process will communicate only with other processes in the same container on the same host, and if using any network resource to achieve "outside world" communication, all will be forwarded to the assigned interface/channel that this container has.



Features



FreeBSD Jails:



  • Considered stable technology, since it is a feature inside FreeBSD since 4.0;

  • It takes the best of ZFS filesystem at the point where you could clone jails and create jail templates to easily deploy more jails. Some more ZFS madness;


  • Well documented, and evolving;

  • Hierarchical Jails allow you to create jails inside a jail (we need to go deeper!). Combine with allow.mount.zfs to achieve more power, and other variables like children.max do define max children jails.


  • rctl(8) will handle resource limits of jails (memory, CPU, disk, ...);

  • FreeBSD jails handle Linux userspace;

  • Network isolation with vnet, allowing each jail to have its own network stack, interfaces, addressing and routing tables;


  • nullfs to help linking folders to ones that are located on the real server to inside a jail;


  • ezjail utility to help mass deployments and management of jails;

  • Lots of kernel tunables (sysctl). security.jail.allow.* parameters will limit the actions of the root user of that jail.

  • Maybe, FreeBSD jails will extend some of the VPS project features like live migration in a near future.

  • There is some effort of ZFS and Docker integration running. Still experimental.


  • FreeBSD 12 supports bhyve inside a jail and pf inside a jail, creating further isolation to those tools

  • Lots of interesting tools were developed during the last years. Some of them are indexed on this blog post.


  • Alternatives: FreeBSD VPS project

Linux Containers (LXC):



  • New "in kernel" technology but being endorsed by big ones(specially Canonical);


  • Unprivileged containers starting from LXC 1.0, makes a big step into security inside containers;

  • UID and GID mapping inside containers;

  • Kernel namespaces, to make separation of IPC, mount, pid, network and users. These namespaces can be handled in a detached way, where a process that uses a different network namespace will not necessarily be isolated on other aspects like storage;

  • Control Groups (cgroups) to manage resources and grouping them. CGManager is the guy to achieve that.

  • Apparmor/SELinux profiles and Kernel capabilities for better enforcing Kernel features accessible by containers. Seccomp is also available on lxc containers to filter system calls. Other security aspects here.


  • Live migration functionality being developed. It’s really hard to say when it will be ready for production use, since docker/lxc will have to deal with userspace process pause, snapshot, migrate and consolidate - ref1, ref2. Live migration is working with basic containers(no device passthrough neither complex network services or special storage configurations).

  • APIs bindings to enable development in python3 and 2, lua, Go, Ruby and Haskell

  • Centralized "What's new" area. Pretty useful whenever you need to check if some bug was fixed or a new feature got committed. Here.

  • An interesting alternative could be lxd, that under the hood works with lxc but, it has some nice features like a REST api, OpenStack integration, etc.

  • Another interesting thing is that Ubuntu seems to be shipping zfs as the default filesystem for containers on 16.04. To keep projects aligned, lxd launched it's 2.0 version, and some of the features are zfs related.


  • Alternatives: OpenVZ, Docker


  • Docker. Note here that Docker uses namespaces, cgroups creating "per app"/"per software" isolation. Key differences here. While LXC creates containers with multiple processes, Docker reduces a container as much as possible to a single process and then manage that through Docker.

  • Effort on integrating Docker with SELinux and reducing capabilities inside a container to make it more secure - Docker and SELinux, Dan Walsh

  • What is the difference between Docker, LXD, and LXC

Docker no longer uses lxc. They now have a specific lib called libcontainer that handles the integration with low-level Kernel namespace and cgroups features directly.



Neither technology is a security panacea, but both are pretty good ways to isolate an environment that doesn’t require Full Virtualization due to mixed operating systems infrastructure. Security will come after a lot of documentation reading and implementation of kernel tunables, MAC and isolations that those OS-Level virt offer to you.



See Also:



  • Hand-crafted containers

  • BSD Now: Everything you need to know about Jails

  • ezjail – Jail administration framework

  • A Brief History of Containers: From the 1970s to 2017


  • Docker Considered Harmful - Good article about the security circus around container technologies.





share|improve this answer














No matter the fancy name used here, both are solutions to a specific problem: A better segregation solution than classic Unix chroot. Operating system-level virtualization, containers, zones, or even "chroot with steroids" are names or commercial titles that define the same concept of userspace separation, but with different features.



Chroot was introduced on 18 March 1982, months before the release of 4.2 BSD, as a tool to test its installation and build system, but today it still has its flaws. Since the first objective of chroot was only to provide a newroot path, other aspects of system that needed to be isolated or controlled got uncovered (network, process view, I/O throughput). This is where the first containers (User-level virtualization) appeared.



Both technologies (FreeBSD Jails and LXC) make use of userspace isolation to provide another layer of security. This compartmentalization will ensure that a determined process will communicate only with other processes in the same container on the same host, and if using any network resource to achieve "outside world" communication, all will be forwarded to the assigned interface/channel that this container has.



Features



FreeBSD Jails:



  • Considered stable technology, since it is a feature inside FreeBSD since 4.0;

  • It takes the best of ZFS filesystem at the point where you could clone jails and create jail templates to easily deploy more jails. Some more ZFS madness;


  • Well documented, and evolving;

  • Hierarchical Jails allow you to create jails inside a jail (we need to go deeper!). Combine with allow.mount.zfs to achieve more power, and other variables like children.max do define max children jails.


  • rctl(8) will handle resource limits of jails (memory, CPU, disk, ...);

  • FreeBSD jails handle Linux userspace;

  • Network isolation with vnet, allowing each jail to have its own network stack, interfaces, addressing and routing tables;


  • nullfs to help linking folders to ones that are located on the real server to inside a jail;


  • ezjail utility to help mass deployments and management of jails;

  • Lots of kernel tunables (sysctl). security.jail.allow.* parameters will limit the actions of the root user of that jail.

  • Maybe, FreeBSD jails will extend some of the VPS project features like live migration in a near future.

  • There is some effort of ZFS and Docker integration running. Still experimental.


  • FreeBSD 12 supports bhyve inside a jail and pf inside a jail, creating further isolation to those tools

  • Lots of interesting tools were developed during the last years. Some of them are indexed on this blog post.


  • Alternatives: FreeBSD VPS project

Linux Containers (LXC):



  • New "in kernel" technology but being endorsed by big ones(specially Canonical);


  • Unprivileged containers starting from LXC 1.0, makes a big step into security inside containers;

  • UID and GID mapping inside containers;

  • Kernel namespaces, to make separation of IPC, mount, pid, network and users. These namespaces can be handled in a detached way, where a process that uses a different network namespace will not necessarily be isolated on other aspects like storage;

  • Control Groups (cgroups) to manage resources and grouping them. CGManager is the guy to achieve that.

  • Apparmor/SELinux profiles and Kernel capabilities for better enforcing Kernel features accessible by containers. Seccomp is also available on lxc containers to filter system calls. Other security aspects here.


  • Live migration functionality being developed. It’s really hard to say when it will be ready for production use, since docker/lxc will have to deal with userspace process pause, snapshot, migrate and consolidate - ref1, ref2. Live migration is working with basic containers(no device passthrough neither complex network services or special storage configurations).

  • APIs bindings to enable development in python3 and 2, lua, Go, Ruby and Haskell

  • Centralized "What's new" area. Pretty useful whenever you need to check if some bug was fixed or a new feature got committed. Here.

  • An interesting alternative could be lxd, that under the hood works with lxc but, it has some nice features like a REST api, OpenStack integration, etc.

  • Another interesting thing is that Ubuntu seems to be shipping zfs as the default filesystem for containers on 16.04. To keep projects aligned, lxd launched it's 2.0 version, and some of the features are zfs related.


  • Alternatives: OpenVZ, Docker


  • Docker. Note here that Docker uses namespaces, cgroups creating "per app"/"per software" isolation. Key differences here. While LXC creates containers with multiple processes, Docker reduces a container as much as possible to a single process and then manage that through Docker.

  • Effort on integrating Docker with SELinux and reducing capabilities inside a container to make it more secure - Docker and SELinux, Dan Walsh

  • What is the difference between Docker, LXD, and LXC

Docker no longer uses lxc. They now have a specific lib called libcontainer that handles the integration with low-level Kernel namespace and cgroups features directly.



Neither technology is a security panacea, but both are pretty good ways to isolate an environment that doesn’t require Full Virtualization due to mixed operating systems infrastructure. Security will come after a lot of documentation reading and implementation of kernel tunables, MAC and isolations that those OS-Level virt offer to you.



See Also:



  • Hand-crafted containers

  • BSD Now: Everything you need to know about Jails

  • ezjail – Jail administration framework

  • A Brief History of Containers: From the 1970s to 2017


  • Docker Considered Harmful - Good article about the security circus around container technologies.






share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 13 at 9:48

























answered Jul 9 '14 at 17:59









nwildner

13.9k14076




13.9k14076







  • 1




    Worth mentioning that out of the box, there is no effort by lxc to provide proper guest isolation. lxd, however, does attempt to provide isolation like BSD jails or Solaris zones.
    – allquixotic
    Jun 23 '15 at 14:06










  • lxd is a "better experience" of LXC, putting other features on top of it. However, it seems nice to quote this little guy in here
    – nwildner
    Sep 21 '15 at 12:22










  • @allquixotic you mean if using unchanged configuration created from templates? True, but unprivileged (userns-enabled) containers were available with LXC 1.x and could even be auto-started at system boot, provided that they were owned by root (and thus located in the system-wide location for containers).
    – 0xC0000022L
    May 3 at 14:47












  • 1




    Worth mentioning that out of the box, there is no effort by lxc to provide proper guest isolation. lxd, however, does attempt to provide isolation like BSD jails or Solaris zones.
    – allquixotic
    Jun 23 '15 at 14:06










  • lxd is a "better experience" of LXC, putting other features on top of it. However, it seems nice to quote this little guy in here
    – nwildner
    Sep 21 '15 at 12:22










  • @allquixotic you mean if using unchanged configuration created from templates? True, but unprivileged (userns-enabled) containers were available with LXC 1.x and could even be auto-started at system boot, provided that they were owned by root (and thus located in the system-wide location for containers).
    – 0xC0000022L
    May 3 at 14:47







1




1




Worth mentioning that out of the box, there is no effort by lxc to provide proper guest isolation. lxd, however, does attempt to provide isolation like BSD jails or Solaris zones.
– allquixotic
Jun 23 '15 at 14:06




Worth mentioning that out of the box, there is no effort by lxc to provide proper guest isolation. lxd, however, does attempt to provide isolation like BSD jails or Solaris zones.
– allquixotic
Jun 23 '15 at 14:06












lxd is a "better experience" of LXC, putting other features on top of it. However, it seems nice to quote this little guy in here
– nwildner
Sep 21 '15 at 12:22




lxd is a "better experience" of LXC, putting other features on top of it. However, it seems nice to quote this little guy in here
– nwildner
Sep 21 '15 at 12:22












@allquixotic you mean if using unchanged configuration created from templates? True, but unprivileged (userns-enabled) containers were available with LXC 1.x and could even be auto-started at system boot, provided that they were owned by root (and thus located in the system-wide location for containers).
– 0xC0000022L
May 3 at 14:47




@allquixotic you mean if using unchanged configuration created from templates? True, but unprivileged (userns-enabled) containers were available with LXC 1.x and could even be auto-started at system boot, provided that they were owned by root (and thus located in the system-wide location for containers).
– 0xC0000022L
May 3 at 14:47

















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f127001%2flinux-lxc-vs-freebsd-jail%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay