We isolate demons with systemd or "you do not need Docker for this purpose!"
1 year, 2 months ago
Recently I see how quite large number of people applies container virtualization only to lock potentially unsafe application in the container. As a rule, use for this Docker because of its prevalence, and do not know anything better. Really, many demons are originally started on behalf of root, and further or lower the privileges, or master-process generates the processing processes with the lowered privileges. And is also such which work only from root. If in the demon find vulnerability which allows to get access with the maximum privileges, it will be not really pleasant to find the malefactors who were already in time to download all data and to leave viruses.
The containerization provided to Docker and other similar software really rescues from this problem, but also and introduces new: it is necessary to create the container for each demon, to care for safety of the changed files, to update a basic image and containers are often based on different OS which need to be stored on a disk though they, in general, also are not especially necessary to you. What to do if you do not need containers per se, in Docker Hub the application is collected not as it is necessary for you and the version became outdated, SELinux and AppArmor seem to you too difficult, and you would like to start it in your environment, but using the same isolation which is used by Docker?
In what difference of the normal user from root? Why root can manage a network, load kernel modules, mount file systems, kill processes of any users, and the normal user is deprived of such opportunities? It is all about capabilities — means for management of privileges. All these privileges are given to the user with UID 0 (i.e. root) by default, and the normal user has no of them. The privilege can both be given, and to select. So, for example, the usual ping command demands creation of a RAW socket that it is impossible to make on behalf of the normal user. Historically, on ping put a SUID flag which just started the program on behalf of the superuser, but now all modern distribution kits expose CAP_NET_RAW capability which allows to start ping from under any account.
It is possible to receive the list of the set file capabilities command
getcap from structure of libcap.
% getcap $(which ping)
/usr/bin/ping = cap_net_raw+ep
P flag means permitted here, i.e. the application has an opportunity to use the set capability, e means effective — it will use the application, and there is still a flag of i — inheritable that gives the chance to save the capabilities list at function call
Capabilities can be set as at the level of FS, and just at a separate flow of the program. It is impossible to receive capability which was not available since launch, i.e. privileges can only be lowered, but not to raise.
Also there are bits of safety (Secure Bits), their three: KEEP_CAPS allows to save capability by a challenge of setuid, NO_SETUID_FIXUP turns off reconfiguration of capability by setuid challenge, and NOROOT prohibits issue of additional privileges at start of suid-programs.
Read more »