http://www.murga-linux.com/puppy/viewto ... 56#1048856But in general the suggested method is to use FreeBSD_jail or KVM instead of chroot.
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.
https://linuxacademy.com/blog/linux-aca ... echnology/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.
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:
https://www.facebook.com/groups/GNUAndL ... 4516595019Clint 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.
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:
https://wiki.archlinux.org/index.php/cgroupsControl 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
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:
https://www.facebook.com/groups/GNUAndL ... 1337960019"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.
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