Hello everyone! Today, I've downloaded EasyOS and tried to run it in a virtual machine. I've looked what applications it has, what features are added, etc. Also, I've looked up the kernel configurations and have some questions:
1. What was the reason behind excluding mandatory access control systems support, such as SELinux, SMACK, AppArmor and TOMOYO Linux during kernel compilation time (pic. 1)? MAC in GNU/Linux can be disabled at boot time so it won't affect system functioning in any way.
2. What was the reason behind disabling Landlock support (pic. 2)? While Landlock is a pretty new technology (it was added in Linux 5.13 version), we can expect that more applications are going to use it in order to restrict their access to the filesystem just like they restrict their access to system calls with seccomp.
3. I've looked how EasyContainers works, and I have found something... disturbing in the EasyOS kernel (pic. 2) -- I just wonder, who could think that disabling the support for user namespaces in the kernel was a remotely good idea? User namespacing is a highly important feature of the Linux kernel that is used to create unprivileged containers and can be used to run untrusted apps in a container. Basically, it removes all parent-namespace capabilities and allows a namespace creator process to "remap" UIDs and GIDs so root in a container would be an ordinary user in the host namespace. In current EasyOS 4.4.3, only privileged containers can be created (even if you replace EasyContainers with LXC, Docker or systemd-nspawn), because there is no support for unprivileged containers in the kernel.
What's more important, there are unprivileged sandboxing tools such as [Bubblewrap](https://github.com/containers/bubblewrap/) that rely on unprivileged user namespaces. Disabling support for user namespaces means that only root can create a namespace sandbox, and adding Bubblewrap to EasyOS would require setting a SUID bit -- something Firejail has been criticized for. It can also cause issues with enabling the "No New Privileges" bit as it forbids any SUID-bit-based privilege elevation.
I hope that this is nothing more than merely a bug caused by a mistake in kernel compilation option choice.