Containerization on Linux in detail - LXC and OpenVZ. Part 1

What is OpenVZ?

OpenVZ development history

• OpenVZ for RHEL4 (closed by EOL)
• OpenVZ for RHEL5
• OpenVZ for RHEL6
• OpenVZ for RHEL7 (while being written)

Linux upstream containers development history

Technical implementation of the container insulation subsystem

1. You can run applications from different Linux users. Thus, the security of the file system of a neighboring application will be controlled solely by the system of rights to Linux files and folders, and if the configuration is incorrect, it may be possible to compromise files. Also, all the service files of the physical server will be accessible to both applications, which can also lead to data leakage and subsequent compromise of the entire system. This method does not solve all the problems and you need something more advanced.
2. To increase the security of the file system, we will try to use the chroot functionality, which allows you to “lock” the process inside a specific folder, from which it will be very difficult for it to get out. To do this, we need to create a complete set of system files (for example, through debootstrap) for each of the applications and put them in separate file hierarchies. Thus, each application will have its own file hierarchy that does not intersect with a friend. But if the process inside the chroot works as the root user (there are quite a lot of such processes), then using standard mechanisms (multiple chroot) he can get out of the chroot and get into the file system of the physical server, which, of course, is not acceptable. This option also does not suit us.
3. In addition to chroot Linux, the Linux mount namespace subsystem has been around for a very long time, which provides broader functionality, but with full protection so that it cannot be pulled out. In containerization it is used. Since it is no longer possible to describe our actions in detail without invoking the C code, I will limit myself to their formal description. So, we have solved the problems of isolating ordinary file systems.
4. Now suppose that each of the applications uses a fixed port, for example, 443d. What should we do if there is only 1 IP address on the server and it is attached to the physical server? Of course, first we need two additional IP addresses, one for each service. We will have to assign both of them to the physical server and configure for each application an explicit listening on its IP address. But what if one of the applications is hacked and tries to start listening on a port on the IP of the physical server or on the IP of the neighbor in order to compromise access? He will succeed and no one will prevent him from doing this. How to deal with this? Here the namespaces will help us again - namely, the network namespace, through which each of the containers (perhaps they can already be called that way!) Gets a strictly fixed separate IP address (as well as the space of sockets, ports, and the routing table). This will ensure complete isolation at the level of sockets, IP addresses and ports from the neighbor. No mutual influence is now possible.
5. And now let's get a little into the jungle of processes and remember that, for example, the Apache web server uses semaphores very actively, and the PHP APC opcode accelerator very often uses shm memory. What happens if one process takes and even clears the memory of the neighbor, which is clearly visible to him? Or read it and retrieve any sensitive data? Strongly unpleasant event that reduces all our tricks on isolation to nothing. But there is a solution - IPC namespace, which isolates semaphores, queues, mutexes, shm memory for IPC and IPC Sys V in the form that each container only sees its own IPC resources and no one else. Hooray! Problem solved.
6. At this stage, we have almost everything fine, but the problem remains with the fact that from the container we see all the processes of the physical server, as well as the processes of the neighbor. Often, processes disclose passwords or other important information in their names, so this possibility is extremely undesirable. In addition, if we want to start a process with a fixed PID, which is already occupied by a neighboring container or host system - this will not work, since Linux requires a unique PID for all processes. To get rid of this behavior, we use the PID namespace, which for each container will create a completely isolated (from the physical server and from the neighbor) PID numbering system, which in turn makes it possible to start, for example, several processes with a PID equal to 1. Stop, and What process on Linux has such a PID? Correct init! In our “self-made insulation” we have reached the stage when we can run a full-fledged system, and not just one process inside the container! Hooray!
7. But our happiness in launching a full-fledged Linux in the container will be incomplete, since the hostnames will coincide in both containers with the hostname of the physical server, which can, for example, when working on ssh lead to unpleasant consequences and a lot of software checks the correctness of the hostname and its consistency IP address of the machine. It also needs to be isolated; this is done with a namespace with a very non-intuitive name - UTS, which only allows you to set each container with its own unique hostname.

• Mount
• Network
• Pid
• UTS
• IPC

What to expect in the continuation?

• Technical implementation of the container hardware resource limiting subsystem
• Common problems when using containers
• The advantages of OpenVZ over standard Linux containerization
• Problem from the user space
• findings