OS Level Virtualization: Containers, chroot, cgroops jails,

[s243a]

I've been recently experimenting with sandboxing and one user suggested the following:

But in general the suggested method is to use FreeBSD_jail or KVM instead of chroot.

http://www.murga-linux.com/puppy/viewto ... 56#1048856

but with such vague statements I wonder, "Suggested by whom and for what purpose". My primary intent of the sandboxing was for a lightweight test environment and not a security mechanism but certainly security is a secondary goal. However, I'm not trying to protect enterprise level servers, I'm not planning on running potentially unsafe applications and I don't think that the data on my computer is that interesting to an attacker.

Sure I understand that things like identity theft can be quite damaging. However, for perspective, I think that by default puppy is much safer than windows even if we can't convince the banks lawyers of this!

The wikipedia page on OS-level virtualization, has a very good table on what various types of OS-level virtualization offer
https://en.wikipedia.org/w/index.php?ti ... mentations

From this table let's take chroot as an example, the table says that it doesn't provide privilege separation. However, what if once we enter the chroot environment we execute a script to drop to a less privileged user?

The table says that chroot doesn't have network segregation but by default on linux non-root users can't setup raw sockets [1]. Also IPTABLES can be used to restrict network activity on a process level basis.

Now one might ask whether various types of OS Level virtualization (e.g. containers) are just added features on top of chroot (or something like chroot) or alternatively something completly different.

On March 4, 2000, FreeBSD introduced the jail command into its operating system. Although it was similar to the chroot command, it also included additional process sandboxing features for isolating filesystems, users, networks, etc. FreeBSD jail gave us the ability to assign an IP address, configure custom software installations, and make modifications to each jail. This wasn’t without its own issues, as applications inside the jail were limited in their functionality.

https://linuxacademy.com/blog/linux-aca ... echnology/

So jails are like chroots. I'm not sure if the ability to assign an IP address to a jail is that special since we can setup IPTABLES rules based on a given process but perhaps jails make this easier when processes fork? My suggestion about dropping user privileges once in a chroot suggests an area where jails might have an advantage.

If there is something called root-privilege isolation perhaps in the jail a user can appear as root but have different privileges than the system root? If so then they could manage things inside the jail or container like a root user but still have restricted privileges on a system wide level? If so then I wonder why there are a bunch of warnings on the web to not run docker as root? Granted docker isn't a jail but I thought container implementations were supposed to be more advanced than jails.

Another idea of how we might implement something like privlage speration with chroot, is to drop to a lower privileged user once in the chroot, than run the proot command so that one can appear as root inside the chroot but have fewer privileges than the system wide root.

Now regarding containers. Containers are supposed to be further along in the evolutionary process of OS level Virtualization. As for what constitutes a container. Here is one users answer on the Linux Facebook group:

Clint Grimsley chroot + cgroups + network abstraction + continuous integration + REST APIs + a security subsystem = containerization (I'm sure there's more that can be thrown in there)

That said, containers can also introduce or exacerbate problems and add lots of moving parts. Worth learning, for sure, but care must be taken if your plan is to rearchitect an already working system. Don't do it simply for the sake of containers.

https://www.facebook.com/groups/GNUAndL ... 4516595019

cgroups seems to be a big one along the history of containers timeline. My guess is that you could run a chroot process as a cgroup. From archwiki:

Control groups can be accessed with various tools:
...
via tools like cgcreate, cgexec and cgclassify (part of the libcgroupAUR package);
using the "rules engine daemon" to automatically move certain users/groups/commands to groups (/etc/cgrules.conf and

https://wiki.archlinux.org/index.php/cgroups

and with the above facebook comment about "a lot of moving parts", this to me says why one might want to use chroot rather than containers. A person might not need all the features of a container and if they don't than perhaps a container provides extra overhead. To me there is merit to having separate tools for each feature rather than using one monolithic tool that does everything. Besides there have been plenty of security warning related to docker and even virtual machines so perhaps more features isn't always better!

As a final note, I'll say that containers can be implemented with chroot as one of the builing blocks but aren't necessarily implemented with chroot:

"Containers make use of Linux kernel features such as Namespaces, Apparmor, SELinux profiles, chroot, and CGroups for providing an isolated environment similar to VMs. "
https://dzone.com/articles/evolution-of ... ers-future

So containers might be implemented via chroot but of course perhaps there are alternative tools one could use instead (e.g. proot)p.

https://www.facebook.com/groups/GNUAndL ... 1337960019

Therefore, let me conclude by saying that if the primary functionality one needs is chroot one should just use chroot rather than something else (e.g. FreeBSD_jail, KVM Virtualization or Docker Containers). Building containers based upon chroot seems to follow the modular design principle that has served linux well in the early days of containers and in this spirit I think that EasyContainers are built using simple tools like chroot rather than monolithic process managers (e.g.pick your system level daemons here, lol).

Notes
-----------------_
1 - For a user to setup a raw socket they need the CAP_NET_RAW user privlage. Some discussion about granting this can be found here: https://unix.stackexchange.com/question ... s-to-users

[jamesbond]

BSD jail = chroot on stereoids.
Linux container = chroot on stereoids.

Difference:
---
- BSD jail is an integrated design. You start a "jail" instead of "chroot"; and you can all the features you want from "jail".
- Linux "container" is a amalgamation of disparate technologies that has evolved over years (some of it was decade old), and implemented piece-meal. You can still use it as is - piece-meal: only use what you want. The actual name of the techonology is "Linux namespace" ("container" is the salesman's terms), plus a few others - capabilities, etc; and obviously "chroot" is one of them.

In Linux, if all you want is testing, and the apps being tested it not hostile, then chroot will do the job. If the app is possibly hostile, then you can use multiple levels of isolation depending on what you really need. Run "unshare --help" and see what I mean; and then you have capabilities and such.